Como diminuir o alto turnover na sua equipe de desenvolvimento

Possuir um alto turnover na sua equipe de desenvolvimento pode ser um fator decisivo para o sucesso de uma empresa. Isso porque, uma empresa com uma alta rotatividade de funcionários tende a não ter continuidade no andamentos dos projetos e faz com que a busca pelo profissional ideal nunca cesse. Além disso, um índice de turnover elevado em uma empresa pode revelar muito sobre a saúde interna do negócio, dos processos e da sua eficiência como um todo.

Mostra também alguns problemas relacionados a gestão, a uma possível falta de investimentos no capital fixo, escassez de ações de reconhecimento e de motivação, entre outros. Ao longo do tempo, os resultados negativos podem se manifestar em grandes e constantes gastos relativos a desligamento de colaboradores, perda de credibilidade e falta de mão de obra qualificada.

Pensando nesse ponto importantíssimo para as empresas como um todo, nós preparamos um artigo que detalha alguns passos para que você consiga diminuir o índice de turnover no seu negócio. Confira a seguir!

Como diminuir o alto turnover na sua equipe?

Invista na comunicação interna

A comunicação interna é outro fator super importante para que os desenvolvedores se mantenham por mais tempo em sua equipe. Abrir ou ampliar canais de comunicação da equipe com setores de liderança da empresa ou somente com as outras áreas do seu negócio consegue promover uma integração maior entre todo o time.

Além disso, essa prática estimula o sentimento de união, de pertencimento dos profissionais com sua empresa e aumenta a troca de experiência. Com o aumento da comunicação interna entre os desenvolvedores, logo você colherá melhores resultados em seus projetos devido ao aumento de entrosamento da equipe.

Atualmente, existem algumas formas de aumentar a comunicação, e, consequentemente, diminuir o índice de turnover. Uma das principais é realizar o investimento em tecnologia, como intranet corporativa, banco de dados compartilhado e outros programas e sistemas de comunicação instantânea, como o Discord.

Outro aspecto que pode fazer a diferença é o reconhecer os resultados da sua equipe. Elaborar ações de reconhecimento de performance e de esforço dos funcionários também contribuem para um aumento de desempenho. Por isso, sempre que possível, invista em bonificações e premiações.

Oferecer benefícios pode ajudar a diminuir o alto turnover

Ainda nessa linha de raciocínio, oferecer benefícios extras aos profissionais pode diminuir ainda mais o alto turnover na sua empresa. Além disso, desenvolver estratégias para aumentar a motivação também pode estimular comportamentos eficientes essenciais e desejáveis para a produtividade do negócio como um todo.

Nesse caso, a estratégia que construir um plano de carreira atraente para o desenvolvedor também pode ser uma solução. Isso porque, o grande percentual de profissionais muda de emprego em busca de perspectivas melhores em suas carreiras, visando uma estabilidade futura. Além disso, aplique formas de remuneração baseadas em desempenho e metas, e na obtenção de resultados operacionais.

Realize capacitações e treinamentos

Outro ponto que pode fazer a diferença para sua empresa é realizar treinamentos para os funcionários contratados. Fazer com que sua empresa tenha a atitude de investir na qualificação dos funcionários contribui para garantir ganho na qualidade do serviço prestado pelos profissionais, aumentando o desempenho dos colaboradores e elevando o nível técnico da equipe nos projetos. O simples fato de o desenvolvedor sentir que está evoluindo junto a empresa faz com que seu negócio seja mais atraente no mercado de trabalho, em relação àquelas que não possuem ações nesse sentido.

Busque realizar um processo seletivo assertivo

Um dos principais fatores que levam a um aumento no índice de turnover é a realização de um processo seletivo com pouca eficiência. É importantíssimo que sua equipe de RH esteja alinhada sobre como encontrar bons profissionais e tenha também bastante conhecimento sobre as vagas abertas na sua empresa. Com isso, é mais fácil encontrar os desenvolvedores ideais que tenham fit cultural adequado com seus valores, diminuindo a taxa de turnover e evitando a rotatividade de funcionários.

Mantenha um ambiente de trabalho agradável

Essa também é uma estratégia importante já que ambiente de trabalho influencia diretamente a produtividade dos funcionários. Ambientes com clima ruim, com inimizades, uma competição acirrada e a falta de equipamentos mínimos para o desempenho da função, podem ser considerados como pontos de desmotivação, baixo desempenho e conflitos internos. Investir em um local de trabalho bem estruturado, equipado, amigável e favorável ao funcionário promove resultados melhores.

Em razão disso, logo você perceberá que, sem um alto turnover, é possível trabalhar melhor e potencializar seus retornos. Lembre-se de que os esforços de fidelização não devem se restringir apenas aos seus clientes ou consumidores. Fidelizar funcionários também é uma ação primordial para que sua empresa se mantenha competitiva no longo prazo.

Backlog: o que é e qual sua importância?

O uso do termo Backlog não é novidade nenhuma na área da Tecnologia da Informação. Uma das etapas do Scrum e uma das metodologias mais utilizadas atualmente, a estratégia é importante para aumentar a efetividade no gerenciamento dos projetos e também para organizar quais funcionalidades devem ter prioridade na hora do desenvolvimento. Com a construção dos backlogs, toda a equipe consegue visualizar as etapas do projeto e saber como será o andamento dos sprints.

Apesar de ser frequente no mundo da tecnologia, a estratégia é bastante comum, podendo ser utilizada em diversas áreas. Mesmo assim, muitas pessoas não entendem o conceito e não sabem exatamente o que é.

Por ter esse nível de importância, produzimos um artigo que apresenta mais detalhes sobre os diferentes tipos de backlog, qual o tipo ideal para cada situação e saiba como aprimorar a estratégia em seus projetos. Veja a seguir!

Afinal, o que é Backlog?

Backlog nada mais é do que um acúmulo de tarefas que precisam ser organizadas em formato de lista para dar início a um projeto. Dentro dessa lista, o Product Owner utiliza técnicas de Scrum e organiza as tarefas que precisam ser realizadas, seguindo uma ordem de prioridade, para que as sprints de desenvolvimento aconteçam com organização.

Além disso, dentro de cada item listado, deve-se conter uma breve descrição da funcionalidade que precisa ser desenvolvida, a fim de sanar possíveis dúvidas que possam vir a aparecer durante a execução da tarefa. Essa ferramenta é importantíssima na organização de projetos já que evidencia em quais aspectos a equipe deve focar e em quanto tempo a atividade precisa ser realizada.

O Backlog também ajuda na comunicação entre o Product Owner e sua equipe, já que as principais ideias estarão descritas e fixadas na lista de tarefas.

Quais são os tipos?

Atualmente, dois tipos de listas de tarefas são utilizadas no desenvolvimento de projetos: o Product Backlog e o Sprint Backlog, que serão explicados a seguir.

Product Backlog

Entre os dois tipos existentes, o Product Backlog é o que define quais serão as etapas do desenvolvimento de um projeto. Como dito anteriormente, antes do começo da produção é necessário que o Product Owner, junto com a equipe, defina um backlog sobre quais serão as prioridades do time durante o processo de desenvolvimento.

Desta forma, o grupo de devs sabe quais funcionalidades são essenciais para o funcionamento geral do produto e, assim, consegue administrar possíveis funções extras que podem ser adicionadas em etapas futuras. É recomendado que o Backlog de Produto seja visível para todos os funcionários de forma clara no espaço de trabalho, podendo se utilizar de lousas, placas ou ferramentas on-line.

Sprint Backlog

O segundo tipo de Backlog é o produzido para alinhar quais etapas serão produzidas em cada sprint de desenvolvimento. Após a divisão de quantos sprints serão necessários para entrega do projeto em tempo hábil, o Product Backlog é dividido na reunião de planejamento chamada de Sprint Planning.

Dessa forma, surge o Sprint Backlog, lista que conterá as atividades que devem ser desenvolvidas em cada período de tempo e qual será o foco da equipe de desenvolvedores em cada sprint. Além disso, é importante lembrar que o Product Backlog é criado apenas uma vez, podendo ser atualizado durante o processo, e o Sprint Backlog é feito em cada etapa do desenvolvimento.

Nesse ponto, é importante definir um tempo fixo para cada sprint acontecer e dividir igualmente as funcionalidades para que nenhuma sprint fique sobrecarregada. Isso porque alterações podem surgir no decorrer do projeto e essas tarefas precisarão entrar em alguma etapa para serem corrigidas.

Como aprimorar?

Entre as formas existentes que permitem melhorar o aproveitamento de sua estratégia estão reuniões quinzenais, semanais e até mesmo diárias. É claro que isso pode variar de acordo com o nível de experiência dos profissionais e a quantidade de desenvolvedores que estão no projeto. Porém, com uma frequência maior de reuniões, é possível alinhar as etapas de produção, dar feedbacks sobre o que pode ser melhorado e até aumentar o entrosamento entre Product Owner e devs.

Além disso, o quanto antes os problemas surgirem e voltarem ao Product Backlog, mais rapidamente as mudanças podem ser incluídas nos sprints e podem ser atualizadas pelos desenvolvedores. Outro ponto importante é que, atualmente, existem diversas ferramentas on-line que permitem acelerar o processo a auxiliar a equipe toda na gestão dos backlogs.

Se você precisa de ajuda para escalar seu time de tecnologia de maneira eficiente, saiba que pode contar sempre conosco, basta entrar em contato!

Learn scrum on the go: Introduction

How to use scrum on the go? And how can we apply it on our work effectively?

If you work with project management or software development, you have certainly heard about Scrum. And probably about some of the famous success cases with your application, like for example, the Spotify storie.

Although we always see the scrum defined as “a simple framework for managing complex projects”. In fact is that it is quite prescriptive, and it takes time for the team to adjust to all of its practices. But we can certainly achieve good results with.

In this article I will talk about the concepts of this framework. This will be the first of a path that I will write, which will go from theory to scrum in practice. Let’s go!

PILLARS

Transparency

All the time you can and should have access to all information related to the project. The idea is for information to be shared, so that managers, customers and stakeholders can access it at any time.

That is why it is important for the team to define which tools they will use to communicate, and which documents they will generate during the process. Since this is not defined by Scrum, which leaves this part up to its own time, so that you can do the best.

A tool that can help with this, originated from another agile methodology or kanban board. Which can give the answers of how all the tasks of the team are.

Inspection

Both the development of activities and the execution of the process itself can be inspected at any time. The inspection intent is that everyone is always aligned on the project situation. But this inspection should not be excessive in the point of hindering or in the development of activities, or in micro-management as people.

In terms of development there are two events to carry out the inspection part, they are the “Daily Scrum” and the “Sprint Review”. The process, on the other hand, can be inspected during a “Sprint Retrospective”. All of these events will be explained below.

Adaptation

The last pillar, guarantee that the Scrum process will always be adapted when necessary. The same is true for the product guidelines, which have shorter cycles of interaction with the customer, also have the possibility of being adapted more easily.

ROLES

Product Owner (P.O.)

Responsible for directing the product, it is he who defines which features will be developed. It also prioritizes them for the team. In addition, he must always make it clear what the objectives of that project are and pass the product on to his team.

Scrum Master (S.M.)

It is the team member who must master Scrum practices. Known as a facilitator, he always assists and ensures that the team is performing the process correctly.

Development Team

Is who develops the product in fact, and has the power to decide the best way to do this. In Scrum, the development team has the autonomy to choose how to develop their tasks, to achieve the project’s objectives. The team must be self-organized and multifunctional.

EVENTS

Sprint Planning

At this meeting, the dev team talks about the items in the product backlog and selects what will enter the sprint backlog. Always respecting the prioritization order defined by the P.O.

In addition, the team also takes the opportunity to debate how the demand will be developed, and at that time the P.O. can explain the requirements and objectives of that user story. Thus, the team will be able to have a clearer understanding, and will be able to jointly define the best way to meet the demand.

Daily Scrum

Meeting that must take place daily so that the whole team is aligned on the progress of the project. It should be done with all members standing, as it needs to be something fast, lasting a maximum of 15 minutes.

Usually developers answer 3 questions:

What was done yesterday?

What do you plan to do today?

Was there or is there any impediment?

Sprint Review

Held at the end of every sprint, this meeting serves to assess whether all work items are in accordance with what the customer expects. Here the team presents what was developed for the P.O., and he will rate the delivery.

In this meeting, the participation of product stakeholders is usual. It is also there that we can keep the product backlog updated.

Sprint Retrospective

Held after the review, the retrospective meeting serves for the team to assess how it is working with the framework itself. That is, how they are using the scrum in practice and what the results are.

Some articles talk about raising negative and positive points of the sprint. But I prefer the authors who suggest using the following questions:

What did we do good?

What do we need to improve?

And for everything that needs to be improved, the team must define an action plan.

ARTIFACTS

Product Backlog

List of product features is created, prioritized and maintained by the P.O., used by the team during the sprint planning.

Sprint Backlog

Functionalities selected from the product backlog, by the development team during planning. Ideally, this list of items should be delivered at the end of the sprint.

Incremental Deliveries

At the end of every sprint, the team must increase the product with a functional delivery.

This was the first article on the “Scrum on the go” path. I gave an introduction to the concepts of this framework. In the second article, you can see how the scrum flow works.

Produtividade no trabalho remoto durante a quarentena

Como manter a produtividade no trabalho remoto? Estamos vivendo um momento sem precedentes, preocupados com nossa saúde, economia do país e de quarentena.

Na área de TI, temos a vantagem de podermos continuar trabalhando mesmo estando de quarentena. Apesar do trabalho remoto ser algo bem mais comum na nossa área, muitas pessoas estão tendo essa experiência pela primeira vez.

A grande questão é que está sendo uma experiência nova para todos nós, pois mesmo aqueles que estavam acostumados e já praticavam o trabalho remoto, agora estão vivendo um momento muito diferente.

Antes trabalhávamos em casa, mas podíamos sair, ver os amigos e os familiares. Pra quem trabalhava em uma empresa com espaço físico, também existia a possibilidade de alternar os locais de trabalho, sem falar nos coworkings abertos ao público.

E pra quem sempre trabalhou no escritório, cercado dos colegas foi uma mudança ainda mais abrupta. Pois além das restrições que todos nós estamos vivendo, essas pessoas também estão tendo que se adaptar com o home office.

Afinal quem já trabalha assim, sabe que ele funciona muito bem, mas que é preciso tomar cuidado com horários, distrações, combinar “limites” com as pessoas da casa, entre outras coisas.

Bom, mas agora vamos falar sobre as dicas para manter a produtividade no trabalho remoto, mesmo durante a quarentena. Bora lá?

Entenda qual horário você é mais produtivo

Uma coisa muito importante é saber em qual horário você consegue produzir melhor. E também saber qual melhor horário do seu dia para que você realize determinada tarefa. No meu caso por exemplo, eu gosto de ler logo de manhã, pois estou com a cabeça mais “livre” e sinto que absorvo melhor o conteúdo.

Procuro escrever em horários que terei menos ou nenhuma interrupção e tudo que envolve a parte criativa prefiro fazer na parte da noite, pois parece que rende mais.

O truque é testar mesmo, tente ler, escrever, estudar e produzir outras atividades em horários diferentes do dia. Depois análise quando você teve melhores resultados e maior facilidade de fazer aquilo.

Obviamente que as funções principais do meu trabalho, preciso fazer durante os horários habituais e resolver o mais rápido possível, principalmente por lidar com pessoas na maioria do tempo. No entanto, existem coisas que podem ser realizadas em horários diferentes, e com o trabalho remoto isso fica mais fácil.

Defina suas metas diárias

O trabalho remoto por si só, já gera uma certa preguiça as vezes. Isso devido ao fato de estarmos em casa, e daquela sensação de que ainda temos muito tempo durante o dia para realizar as tarefas.

Com a quarentena, essa situação se agravou um pouco mais. Afinal, “Se eu acabar tudo, o que tenho pra fazer depois?” ou então “Eu tenho muito livre agora, não tenho nada para fazer além de trabalhar”. Bom, esses e outros pensamentos podem passar pela nossa cabeça e são péssimos conselheiros.

É fato que a situação é preocupante e um pouco desanimadora, então ter metas diárias pode ajudar. Defina algumas metas no seu dia, como por exemplo: terminar o relatório, finalizar o artigo, liberar a feature no ambiente de teste, enfim, o importante é definir suas metas diárias.

Isso vai ajudar você a se desafiar, querer cumprir essas metas e não tem nada melhor do que olhar para sua lista de metas e ver elas todas riscadas por terem sido realizadas, dá uma sensação de dever cumprido e ânimo.

Priorização me ajuda a ter mais produtividade no trabalho remoto?

Além das metas diárias, que são as atividades “maiores” que você vai entregar no seu dia, é legar ter uma lista de tarefas a fazer. Os famosos “to do list” ajudam bastante nisso.

Durante a quarentena podemos ficar com essa sensação de que temos muito tempo e que dá pra fazer as coisas conforme forem aparecendo, mas isso é um erro. Prioridade é essencial.

A intenção é anotar tudo o que você precisa fazer, e sempre manter essa lista priorizada. Devemos sempre lembrar que priorização é fundamental, essa ideia de que tudo é prioridade não existe. Pois dizer que tudo é prioridade, é o mesmo que dizer que nada tem prioridade.

Existem ótimos aplicativos para isso, alguns podem ser usados também para anotações e tem até listas compartilhadas. Como por exemplo, o Notion, o Microsoft To Do, entre outros.

Saiba quando parar

Sempre quando falamos de produtividade no trabalho remoto, são levantados pontos da preguiça e das distrações e isso realmente acontece. E agora na quarentena temos alguns pontos mais agravantes como já citei no artigo.

No entanto, devemos também nos atentar em quando devemos parar. Pode parecer sem sentido, mas essa mesma ideia de que não temos outras coisas a fazer além do trabalho pode ser uma armadilha.

O computador está ali do lado, e você recebe uma mensagem, então resolve um problema, depois outro e quando vê já se passaram 2h. Claro que existem coisas urgentes e algumas vezes estamos no ritmo de alguma atividade que não queremos parar, mas não adianta muito se matar de trabalhar 1 dia da semana e passar os próximos 3 trabalhando cansando ou com preguiça. Descansar, se distrair e saber quando parar é muito importante.

Bom pessoal por hoje é isso, espero que essas dicas ajudem todos a se manterem produtivos no trabalho remoto. Ah, e quem quiser ver um pouco sobre o assunto, o Gabriel fez um artigo com 6 dicas para se bem no trabalho remoto, confere lá.

Modelo Spotify Squad: Entenda como ele funciona

Compreender diversos modelos de organização para empresas é essencial. Isso porque existem vantagens associadas aos mais variados métodos. Eles podem atender desde quem busca aplicar uma nova ideia de organização até quem procura revisar a tecnologia social utilizada em sua empresa. E, em todos esses casos é quase inevitável se deparar com um case específico: o Modelo Spotify Squads.

A estrutura desenvolvida pela empresa de streaming de música é a menina dos olhos de diversas startups. Contudo, se basear no conceito da empresa sueca demanda um estudo aprofundado. Além de compreender o caso do Spotify é necessário ter um vasto conhecimento da própria empresa para, então, tentar colocar algo em prática.

Como funciona o Modelo Spotify Squads?

A metodologia adotada pela empresa de streaming está endemicamente relacionada aos conceitos do manifesto ágil. No caso da companhia, o modelo pensado sofreu fortes influências de métodos como o Scrum, especialmente na definição de grupos multidisciplinares e no conceito de autonomia.

O Modelo Spotify, entretanto, aprofundou alguns mecanismos encontrados em métodos de administração já existentes. A ideia central é a adoção dos chamados squads. Esses grupos são compostos por membros de diferentes especializações e funcionam como células individuais dentro da empresa. Isso significa que cada squad tem total autonomia no desenvolvimento de sua feature.

Para ficar mais simples, imagine que cada um destes grupos é a peça de uma casa de brinquedo montável. As paredes são produzidas e funcionam independentemente do teto, que também é independente da porta. Nessa analogia, as paredes podem ser o player do aplicativo web, enquanto o teto é sua biblioteca e a porta a interface de playlists.

Desta forma, o time envolvido no desenvolvimento de cada tarefa não depende de nenhum outro. Para que isso funcione, eles são formados por membros com diferentes skills, garantindo toda a interdependência necessária.

Apesar de possuírem autonomia, os squads, naturalmente, são guiados pela cultura e pelos objetivos da empresa. Sua existência não significa ausência de interação de setores dentro da organização. A comunicação e o foco na interação pessoal são fundamentos do conceito de agilidade. Por isso, existem mais estruturas dentro do Modelo Spotify que possibilitam a troca de experiência entre os colaboradores e os próprios squads.

O que são tribos, capítulos e guildas?

A autonomia dos times dentro da empresa tem como objetivo deixar o trabalho mais ágil e dinâmico, e não travá-lo. Para aumentar a dinamicidade das equipes, existem outras configurações dentro desse conceito de organização. Confira!

Tribos

Também chamadas de tribes, são compostas por squads que trabalham em features com objetivos similares. O objetivo é que a comunicação entre este grupo seja sempre facilitada, seja com reuniões ou proximidade dentro da própria empresa.

Pensando no próprio produto do spotify, podemos imaginar que cada funcionalidade da playlist é desenvolvido por uma squads. E todas essas squads juntas formam a tribo responsável pelo recurso playlist.

Capítulos

Os chapters são formados por membros de diversas squads. Contudo, esta formação não é arbitrária. Todos os membros de um capítulo possuem as mesmas skills e desenvolvem a mesma função dentro de seus respectivos squads — um capítulo pode ser formado por diversos designers por exemplo. Aqui também há outra figura de liderança, responsável por desenvolver colaboradores orientado por suas funções.

Guildas

Traduzidas do termo guilds, estes grupos se formam organicamente. As guildas são compostas por colaboradores de qualquer área e funcionam como uma espécie de grupo de estudos baseados em interesses comuns.

Afinal, devo aplicar o Modelo Spotify Squads?

Antes de tudo, é preciso compreender este tipo de modelo como um conceito. Apesar de se mostrar funcional para um tipo de realidade, o Spotify Squads pode não ser adequado para sua empresa e produto. Diferente do Scrum ou do Kanban, por exemplo, que representam métodos de organização, o Spotify Squads não é um framework ou metodologia ágil generalista. Ele foi pensado e desenhado para um modelo de trabalho específico, baseado em um produto.

Para pensar em se inspirar pela metodologia adotada na empresa de streaming é necessário, primeiro, olhar para o seu próprio negócio. Analisar o capital humano, a estrutura física e o produto é essencial para cogitar um novo modelo para o seu negócio.

Então, respondendo a pergunta: reproduzir o Modelo Spotify pode funcionar? Sim! Nada garante que ele não possa ser efetivo em determinadas startups, mas mesmo assim com certeza serão necessárias algumas adaptações. Contudo, é preciso se perguntar se este modelo irá funcionar com certeza. E, para essa indagação a resposta é não. A organização da empresa depende da aplicação de métodos organizacionais que condizem com a própria realidade, e por isso, nem sempre será possível pegar toda a metodologia do spotify e implementar no seu time. O ideal é utilizá-la apenas como base, e adaptar os processos de acordo com a sua realidade, o seu produto e a sua equipe.

Para saber mais sobre metodologias ágeis e como você pode estruturá-las em sua startup, confira nossos outros conteúdos sobre Agilidade, aqui no nosso Blog.

Precisa de ajuda para escalar seu time de tecnologia de maneira eficiente? Saiba que pode contar sempre conosco, basta entrar em contato e escalaremos o melhor time com a agilidade que você precisa!

Como montar um kanban eficiente?

Quando falamos em kanban, a primeira ideia que normalmente vem a cabeça é um quadro com várias colunas sequenciais. E se você também pensou isso, já sabe bem do que estou falando.

O quadro kanban, realmente é formado por colunas de um fluxo de trabalho, tem começo, meio e fim. Mas como já falei em um artigo sobre conceitos e origem do Kanban, a metodologia vai muito além disso.

No entanto, nesse artigo não vou abordar tanto os conceitos e princípios da metodologia. Quero focar mais no Downstream kanban, que basicamente é o quadro do time de desenvolvimento. Se você quiser saber como funciona esse conceito de separar o quadro da gestão e do time de desenvolvimento, dê uma lida no artigo sobre Upstream kanban.

Bem, já estamos alinhados, então bora para as dicas de como montar um kanban eficiente para o time de desenvolvimento.

Por onde devo começar a montar meu kanban?

O ponto de partida é mapear seu workflow completo. Ou seja, quais são as etapas pelas quais uma demanda passa, desde o momento que ela chega refinada para o time de desenvolvimento. Até o momento que ela é, efetivamente entregue para o cliente.

Destaquei a palavra refinada acima, pois devemos lembrar que para uma demanda chegar no board do time de desenvolvimento, ela precisa estar definida e refinada.

Depois de mapear todo o seu fluxo, crie as colunas do quadro. Lembre-se que as colunas devem representar o seu fluxo de trabalho atual e não aquele que você idealiza. Ficar adicionando passos a mais neste momento vai atrapalhar o time, a evolução é um próximo passo.

É importante também avaliar a necessidade de criar as colunas de espera, por exemplo: você cria a coluna “Em teste”, mas o ideal é ter uma “Aguardando teste” também. O Kanban nos ajuda muito a identificar GAPs, e algumas vezes a tarefa fica mais tempo na coluna de espera, do que na de ação. Isso precisa ser medido.

Lembre-se também de validar e simular todo o fluxo do quadro kanban com o time. É essencial que todos entendam o que cada coluna representa.

Qual o fluxo ideal para o meu kanban?

Quando se trata de Kanban, podemos adaptá-lo da melhor forma possível. Como já falei acima, ele é um processo evolucionário, devemos começar com o básico e evoluí-lo junto com o time.

Mas falando em template, temos passos que normalmente fazem parte do fluxo de trabalho de alguns de times de desenvolvimento.

Vou citar algumas dessas etapas abaixo, e se fizer sentido você pode incorporá-las ao quadro kanban do seu time.

Pronto para desenvolver

Coluna onde ficam todas as tarefas que estão prontas para o time iniciar o desenvolvimento. Se quiser dicas definir bem as atividades para o time, leia esse artigo aqui: Como escrever tarefas para o time de desenvolvimento?

Em desenvolvimento

Todas as atividades que estão sendo desenvolvidas pelo time. É importante que nenhum membro da equipe pode estar desenvolvendo duas tarefas ao mesmo tempo, então só pode haver uma tarefa no nome de cada pessoa, nessa coluna.

Em casos de urgência como bugs ou nova priorização de atividades, é necessário dar um destino para o card com no qual o desenvolvedor estava trabalhando antes.

Pronto para Revisão de código (Code Review)

Se dentro da sua empresa existe a cultura de Code Review entre os membros do time, é interessante manter essa coluna. Onde ficarão as atividades que estão aguardando o Code Review.

É importante avaliar a necessidade dessa coluna, se houver automatização entre o repositório do código e o canal de comunicação do time (Slack por exemplo). E a equipe já tenha a cultura de realizar o code review, talvez essa coluna não seja necessária, e você pode colocar apenas a próxima.

Em Revisão de Código

Toda atividade que for desenvolvida por um dev X, terá o código revisado por outro dev Y. Lembre-se que revisão de código precisa ser baseada em padrões e boas práticas escolhidos pelo time, e que isso não é o mesmo que o trabalho da fase de teste (QA).

Pronto para testar

Aqui vão ficar as atividades que estão prontas para serem testadas. Ou seja, se você tiver um ambiente de QA, a feature precisa estar disponível nesse ambiente para entrar nessa coluna. Normalmente existe um gargalo nessa coluna, se não houver um profissional de QA no time.

Por isso é importante manter o mapeamento dessa coluna.

Em teste

As atividades que estão sendo validadas. Enquanto o teste não for finalizado, a atividade continua aqui.

Pronta para homologação

Se o seu cliente participa do processo de validação, e isso vai depender do momento que o projeto está, essa fase é importante. Da mesma forma da pronto para teste, o card deve entrar aqui quando a atividade estiver disponível para o cliente homologar.

Lembre-se que o nome pronto para homologar é proposital, pois a demanda só estará pronta se o cliente tiver acesso ao ambiente e os dados necessários para teste. Como usuário e senha por exemplo, é básico mas as vezes esquecemos desses detalhes.

Em homologação

Aqui ficam os cards referentes as tarefas que o cliente está homologando. Se for possível utilizar um board que o cliente tenha acesso, será muito bom. Dar visibilidade do andamento do trabalho pra ele, é fundamental.

Pronto para publicar

As tarefas que foram aprovadas pelo cliente, e estão aguardando para serem publicadas no ambiente de produção. Se o seu time tiver um processo de deploy automático, não há necessidade de manter essa coluna.

Finalizado

Finalmente, acabou! Atividades finalizadas, tudo certo.

Bem, essa é uma estrutura sugerida para você montar seu downstream kanban. Mas com certeza cabe adaptações, é sempre necessário avaliar aquilo que faz sentido para o seu time.

Qualquer dúvida, deixe nos comentários.

Comunicação interna: Entenda a importância dela

Você acredita que a comunicação interna nas empresas é importante?

Bom, é fato que esse é um assunto debatido constante dentro das empresas.

Hoje dia podemos observar que grandes e pequenas empresas tem percebido o valor da boa comunicação, e se beneficiado disso.

Mas afinal de contas como podemos avaliar se temos uma boa comunicação. E além disso, o que podemos fazer para melhorá-la?

Neste artigo vou fazer um resumo dos problemas mais comuns encontrados nas empresas. E como podemos mitigá-los.

Identificando os problemas na comunicação interna

Os problemas ocorrem tanto na esfera interna, entre gestão e equipe. Quanto na esfera externa, cliente e time de desenvolvimento. Porém, nesse artigo irei focar mais nos problemas de comunicação interna.

Se você trabalha como desenvolvedor ou gestor de projetos de tecnologia, com certeza já se deparou com problemas de comunicação.

Quem nunca esteve em um projeto, que no momento da entrega final de uma feature, descobre que o cliente esperava outra coisa?

Ou então, aquela demanda que a equipe de desenvolvimento precisa refazer várias vezes, pois os critérios de aceite não foram bem definidos?

Até mesmo, uma tela que está com o layout errado, pois o fluxo não foi passado corretamente para o time?

Aposto que você já passou por algumas dessas situações. Alguns desses pontos estão ligados também a uma má gestão do projeto, mas é fato que a boa comunicação poderia minimizar os impactos desses erros.

Então, se o seu time está tendo muito retrabalho nas entregas, se existe muita incerteza durante o desenvolvimento. Se alguém da equipe sai fazendo algo que não estava priorizado, e se a entrega não acontece no prazo. Vocês tem problema de comunicação interna.

Possíveis causas

Em empresas com uma hierarquia muito vertical, é comum existirem problemas de comunicação. Normalmente os gestores conversam com o cliente, e o time de desenvolvimento nunca participa do entendimento do problema. Em alguns casos, o time não participa nem mesmo da elaboração da decisão.

É claro que em projetos maiores, com grandes equipes nem sempre é possível envolver todos no processo de decisão. Mas sem dúvidas é importante que todos entendam o rumo do projeto.

A equipe de desenvolvimento deve ser parte da solução e entender o rumo do produto. Ganhamos muito quando temos a contribuição do time de desenvolvimento na busca das soluções, mesmo que seja de apenas uma parte do time.

Um dos grandes problemas são gestores que decidem tudo, sem se preocupar com as dores ou problemas do desenvolvimento. Por outro lado, temos também o desenvolvedores que não compartilham esses problemas, por acharem que a gestão está desinteressada.

Além disso, também existem pessoas que não compartilham informações, técnicas ou de negócio, por medo de se tornarem desnecessárias para equipe. Acreditando que reter informações, irá torná-las indispensáveis.

A boa comunicação interna de um time, está ligada também com a cooperação de todos os envolvidos no processo.

Por que a comunicação interna é importante?

Segundo uma pesquisa PMI sobre comunicação, 80% dos projetos que possuem uma comunicação eficaz realizam as entregas no prazo, dentro do orçamento esperado e atingem as metas originais. Isso é o mundo perfeito, não é mesmo?

Você pode conferir mais detalhes desse estudo, nesse link aqui!

Afinal, como podemos melhorar a comunicação interna?

Bom, o primeiro passo é conscientizar as pessoas de que a comunicação é importante para os projetos.

Uma forma de fazer isso, é levantar os problemas que os times tem tido no dia a dia, e se for o caso mostrar que a maioria deles são provenientes de uma comunicação ineficaz.

Podemos também olhar para as metodologias ou frameworks ágeis, que sempre abordam a importância da comunicação. E além disso, nos oferecem ferramentas para melhorarmos isso.

O scrum por exemplo, tem eventos específicos que nos dão um bom direcionamento nesse aspecto. Planning, daily e retrospective são ótimos exemplos, que podem ser adaptados para o seu projeto e equipe, mesmo que não estejam utilizando esse framework. Se quiser saber um pouco mais sobre esses eventos, leia esse artigo Scrum na prática: Introdução.

A utilização de ferramentas onde toda a equipe pode ficar a par do que está acontecendo no projeto. Como por exemplo: Slack, RocketChat e até mesmo WhatsApp também podem ajudar muito.

Assim como manter um diretório compartilhado, onde todos os documentos relacionados ao projeto, ficam disponíveis para toda equipe.

Mas no final, o que realmente faz diferença é ter uma equipe unida em prol do projeto. Uma gestão que entenda a importância de manter a equipe de desenvolvimento a par de tudo o que está acontecendo no projeto. E um time que goste de compartilhar seus conhecimentos técnicos e de negócio.

A boa comunicação interna é fruto de uma equipe engajada, atualizada e colaborativa. Gerenciada de forma inteligente e munida de boas ferramentas de comunicação.

Bom, espero que esse artigo tenha gerado alguns insights e possa contribuir com você e seu time. Até a próxima!

Kudos: O que eles são dentro da gestão de equipes?

Você já ouviu falar sobre Kudos?

O nome pode ser meio estranho, porém é uma ferramenta simples e que pode mudar muito o ambiente da sua empresa.

Se você trabalha com gestão de equipes e pessoas, sabe que a prática do reconhecimento e gratidão são muito importantes. Através dessas práticas podemos melhorar e manter um ambiente saudável na empesa.

Os Kudos podem auxiliar muito nesse processo. Mas afinal o que é isso, e como funciona?

Confere esse post, que você vai entender tudo o que precisa para aplicar isso com sua equipe.

O que são os Kudos?

Os Kudos são cartões para escrever agradecimentos, ou reconhecer o trabalho de um colega. Pode-se também usá-los para parabenizar a equipe de um projeto ou setor da empresa.

A ideia como já mencionei anteriormente, é ajudar a criar um ambiente mais agradável dentro da equipe e até mesmo da empresa. Afinal, quem não gosta de receber um elogio ou ter seu trabalho reconhecido?

Os cartões (kudos) podem ser aplicados até mesmo de forma digital. Mas eu particularmente prefiro utilizar os cartões físicos, acho que fica mais pessoal e tem mais efeito nas pessoas.

Fazendo uma busca na internet, você pode encontrar templates prontos para baixar, com cabeçalhos como “Parabéns”, “Bom trabalho” entre outros. Isso tudo ajuda a deixar a dinâmica mais divertida, e a envolver mais pessoas.

No site da Liga Ágil, tem uns templates bem interessantes para galera geek. Confere aqui!

Como funciona?

Bom, apenas para esclarecer, existem várias formas de aplicar a ferramenta dos kudos na sua empresa. Neste post eu vou explicar como fizemos a aplicação em nossas equipes e empresa.

Primeiramente, você precisa baixar o template dos kudos e imprimir alguns cartões. Ou se preferir pode deixar só alguns post-its para que as pessoas possam escrever, e depois utilizar a versão dos cartões decorados.

Para quebrar um pouco a timidez das pessoas, coloque uma urna (KudoBox) do lado dos cartões e canetas coloridas. Ai elas poderão escrever as mensagens, e colocá-las na urna após terminar.

O cartão deve conter o nome de quem está escrevendo o Kudo e o seu destinatário, além da mensagem é claro.

Depois, defina uma cadência para abrir a urna, pode ser uma vez por semana. Peguei todos os cartões e coloque no Kudo Board. Que é um quadro, onde ficarão todos os cartões.

É importante que este quadro fique em um local onde todas as pessoas da empresa tenham acesso. Além disso, é bom que fiquem é um local onde todos passem diariamente, mas que não atrapalhe a circulação das pessoas.

Depois de expostos, as pessoas que receberam os Kudos podem retirá-los do board e guardá-los ou colocá-los na sua mesa de trabalho. É legal pedir para que deixem os Kudos ali por um tempo, pelo menos até a próxima remessa ser colocada. Assim todos podem ver e o board sempre estará cheio.

Um passo além

Depois que os Kudos tiverem se tornado rotina dentro da empresa, é interessante acrescentar mais recursos.

Como por exemplo, toda vez que abrir a urna marcar o nome de quem escreveu e recebeu os Kudos. Assim pode rolar uma premiação no final ou meio do ano, para aquele que fez o maior número de doações, e também para o que mais recebeu. Dependendo do tamanho da empresa, e quantidade de Kudos, pode-se fazer isso até em ciclos menores.

Lembrando é claro, que você também pode deixar que as pessoas simplesmente escrevam o cartão e coloquem direto no board. Sem ter a necessidade de passar pela urna.

No entanto nas experiências que tive, percebi que a urna ajuda a diminuir a inibição do pessoal no começo. E claro, além disso a urna ajuda a ter mais alguns recursos, como o exemplo de premiação que citei acima.

E ai, gostou da ideia? Se precisar de ajuda para implementar isso na sua empresa, ou quiser compartilhar alguma experiência com o uso de Kudos, deixe nos comentários.

Upstream kanban: o que é e como funciona?

Já ouviu falar de upstream kanban? Sabe como funciona?

Bem, nesse artigo vou dar uma breve explicação sobre o que é upstream kanban e como ele funciona? Confere ai.

O que é upstream kanban?

O upstream kanban, é o quadro com um workflow que precede o desenvolvimento. Normalmente utilizado pelo P.O., P.M. ou qualquer outro tipo de gestor de projeto.

Ele é formado pelas fases que antecedem o downstream kanban, que é o quadro utilizado pela equipe de desenvolvimento.

O upstream kanban é uma ótima opção, para garantir que a demanda chegará para o dev team, bem definida e refinada. As fases que o compõe são customizáveis de acordo com as necessidades do projeto e também formação da equipe.

Quais as etapas do upstream kanban?

Assim como no kanban de desenvolvimento, no upstream kanban você deve definir as etapas de acordo com o seu fluxo de trabalho. E também deve encará-lo como um processo evolucionário.

Ou seja, não adianta você colocar uma infinidade de etapas, se não houver tempo ou necessidade de executá-las. A ideia aqui é garantir uma demanda bem definida para o seu time, mas algo que seja possível de se realizar e tempo hábil. Afinal, não queremos criar gargalos, antes do desenvolvimento iniciar.

Entrada

Nessa fase são adicionadas as demandas que são puxadas do backlog do produto. Aqui também podem surgir demandas novas, que o cliente ou o próprio P.M. do produto acreditam ser necessárias, considerando o negócio e o momento do mercado.

Pré-refinamento

Nessa etapa, o gestor do projeto deverá ter um entendimento melhor da demanda. Sendo assim, o cliente é um papel fundamental aqui. Pode-se também envolver stackholders e até mesmo pessoas do dev team que tenham conhecimento do negócio.

Refinamento

Depois de entender o objetivo da demanda, está na hora do gestor do projeto definir os critérios de aceite que devem ser cumpridos para realização da demanda.

Além disso, ele pode também escrever os casos de teste para garantir a entrega. Nessa fase, são criados os chamados épicos.

Quebra

Após ter definido o que deverá ser desenvolvido e entregue pelo time. O gestor pode juntamente com a equipe de desenvolvimento, realizar a quebra dos épicos.

Eles devem ser divididos em atividades menores, para facilitar o desenvolvimento e entendimento do que precisa ser feito.

Neste artigo, Como escrever tarefas para o time de desenvolvimento?. Eu falo um pouco sobre a estrutura dos cards do board. Isso pode ajudar no entendimento do time.

Priorização

Depois de realizar todas essas etapas, chegou a hora de priorizar as atividades que precisam ser desenvolvidas.

Neste momento, o gestor deve considerar não só uma ordem lógica de tarefas que possuem dependência entre si. Mas também o que agrega mais valor para o negócio.

O que vem depois do upstream kanban?

Ao final do upstream kanban, começamos o fluxo do downstream kanban. Este último, é o board do desenvolvimento em si.

No artigo Kanban aplicado ao desenvolvimento de software, eu falo um pouco sobre os conceitos e como estruturar um kanban para o seu time.

Indo um pouco além…

Da mesma forma que monitoramos o dowstream, podemos também medir os resultados do upstream kanban. Então a pergunta que fica agora é Como medir os resultados do Kanban?

Devemos lembrar que o Kanban é um fraemework muito eficiente, e que pode auxiliar muito na identificação de gargalos no processo e o que precisa ser melhorado. Por isso, é uma ferramenta poderosa que pode ser utilizada em um processo de melhoria contínua.

Ficou com alguma dúvida? Deixe seu comentário.

Kanban X Scrum: qual devo utilizar no meu projeto?

Kanban X Scrum, qual o melhor para o meu projeto?

Se você gosta de gestão ágil, com certeza já caiu nessa questão. Mas afinal de contas, qual devo usar para gerenciar meu projeto? E qual deles vai se adequar melhor a realidade da minha equipe?

Bom, nesse artigo vamos ver algumas comparações entre os dois, para entender melhor as características de cada um. E no final, você poderá avaliar com mais clareza, qual deles é melhor para o seu projeto.

Kanban: Uma breve visão

O método Kanban, foi inspirado no sistema de produção Just In Time (no momento certo). A ideia é que as tarefas sejam executadas em etapas, e sob demanda. Para utilizar os recursos de forma inteligente, sem desperdício e mantendo o fluxo de trabalho em funcionamento constante.

A partir dessa ideia, foi concebido o método Kanban e seus princípios. Ele, se tornou uma ferramenta importante, e que pode ser utilizado não só como uma metodologia de desenvolvimento de software, mas também como um gerenciador do seu fluxo de trabalho.

O Kanban, assim como outras metodologias ágeis, é um processo evolucionário. Por isso, você pode começar com uma implementação simples e evoluir isso com o tempo.

Se tiver mais interesse em Kanban, dá uma olhada nesse artigo!

Scrum: Entendendo como funciona

O scrum é um framework ágil, que pode ajudar muito na organização do seu projeto e também da sua equipe. O nome scrum veio de uma famosa jogada de Rugby, onde basicamente o time todo se une para conseguir marcar o ponto.

Por esse motivo, o scrum não é apenas uma boa ferramenta para o seu projeto, ele pode ajudar também, a melhorar o processo para a equipe como um todo.

O scrum possui 3 pilares, transparência, inspeção e adaptação. Ele considera todo o time de desenvolvimento, stackholders e cliente, e com isso pode gerar um engajamento maior dos envolvidos no projeto.

Além disso, ele também é um processo evolucionário, que pode ser melhorado com o tempo e se adequar ao que sua equipe precisa.

Se você quer entender melhor sobre o Scrum, dá uma olhada nesse artigo!

Kanban X Scrum: Principais diferenças

Agora que já falamos resumidamente de cada um, vamos falar do Kanban X Scrum e entender as principais diferenças entre eles.

Kanban

Fluxo puxado: As atividades são adicionadas na “esteira de produção”, conforme a demanda do time.
Visualização do trabalho em andamento: O board auxilia muito o gestor do projeto, a ter uma ideia do status do projeto e por isso, na tomada de decisões também.
Terminar mais tarefas ao invés de começar novas: Por ter um fluxo puxado, no Kanban sempre prezamos em finalizar atividades em andamento.
Limitação de WIP (Work In Progress): Limitar a quantidade de trabalho em andamento no board, ajuda o time a focar mais na entrega. E limitar o WIP por coluna do board, ajuda a evitar GAPs nas fases do projeto.
Maior adaptabilidade em projetos de manutenção: Pelo trabalho ser passado ao time, com o princípio “on demand“, fica mais fácil encaixar demandas de última hora no fluxo. Como bugs por exemplo.

Scrum

Fluxo empurrado: Normalmente através do ritual de Planning Poker, o time define quantas atividade vai entregar no período da Sprint.
Papéis definidos: Apesar de ser uma framework adaptável, o scrum exige papéis que são fundamentais para ele funcionar.
Eventos determinados: O scrum possui eventos definidos, que podem ter sua cadência adequada as necessidades da equipe. E todos eles com um timebox recomendado.
Maior dificuldade com projetos de manutenção: Apesar de ser sim possível executar um projeto de manutenção com o scrum, ele é um pouco mais complicado. Isso devido ao controle de atividades da sprint, onde o time define previamente o que vai entregar. E quando surge um bug de última hora, é preciso encaixá-lo, podendo tirar uma tarefa que estava planejada.

Mas afinal, qual devo utilizar?

Isso tudo depende do que sue projeto precisa e de como seu time funciona. Eu recomendo utilizar scrum em projetos que estão começando, e depois o Kanban quando o projeto entrar em fase de manutenção. No entanto os dois funcionam nos dois cenários.

Kanban

Se você deseja metrificar suas entregas por exemplo e ter maior previsibilidade, o Kanban pode funcionar muito bem. Afinal você não vai se basear em estimativas, mas em um histórico do que o time já entregou.

Algumas métricas como Lead Time e Througput, são simples de controlar com o uso do Kanban e também fáceis de entender. Se quiser saber mais do assunto, leia esse artigo: Como medir os resultados do Kanban?

Scrum

Já o scrum é muito bom para ajudar a organizar a “casa”. Equipes que estão com dificuldades de priorizar suas atividades, e não tem muita regularidade nas reuniões de projeto, podem se beneficiar muito do uso scrum.

Fazer o planejamento do que será entregue, revisar o trabalho que foi feito. E fazer uma retrospectiva de como a equipe está trabalhando, são alguns dos eventos do scrum que podem ajudar nisso.

E claro, temos o melhor dos dois mundos o Scrumban, que reúne os rituais do scrum e modelo de gerenciamento do Kanban. É uma excelente forma de trabalho, que pode auxiliar você e seu time.

No artigo de Scrum no dia a dia, eu falo um pouco sobre o uso do Kanban em conjunto, e algumas outras dicas que podem ajudar na implementação do scrum.

Extras

Para finalizar, tem também esse vídeo onde falo um pouco sobre Kanban X Scrum.

Espero que tenham gostado do artigo e que ele possa auxiliar você e seu time no momento de fazer essa escolha. Se tiver alguma dúvida, deixe nos comentários. Até a próxima!