Usually some concerns are highlighted: How will we manage to coordinate the work with the team distributed? How will we be able to work without the same social interaction that we had in the common workplace? And what about the impact for people?

Agility, especially Scrum, which recommends that teams work together, in the same place, can obviously be adapted so that that place can be “built” virtually. A few tools and agreements between the team are enough for everything to work well, even better than before, in terms of productivity.

Recently, in an edition of Agile Beer, we raised this debate and there was a lot of feedback from professionals from companies around the world. We try to organize everything and, together with other reports presented in articles that we access, we have prepared a compendium of suggestions to help you deal with this novelty easily. Not everything needs to be implemented. In fact, some solutions overlap. Select and adapt the ones that best help your teams.

Hold virtual meetings, but limit the amount

Many professionals complain about the increase in remote work meetings. Natural, because some meetings that were in person and the professional was not even close, now go straight to your desktop. It became more difficult to say that you will not be able to go, because now the meeting is coming. In addition, it was easier to schedule a meeting, as you do not need a room, an audiovisual resource or water and coffee. Each one turns around.

Too many meetings tire the team and negatively affect productivity. A good way is to combine with the team what demands a meeting, establish limits for the duration of the necessary ones, and even set a specific day / period for meetings that are not already foreseen in the adopted work process.

Establish a comfortable and common schedule

Remote work at home ends up changing both the individual’s routine and that of his home. Adaptations to schedules and family interactions turn out to be necessary. However, not all families are equal and have the same demands. You can’t always schedule meetings or try to work together whenever you like. It may be that this time does not please the rest of your team.

A good practice is to establish a daily schedule when everyone on the team must be available for work, a common schedule, which facilitates the exchange of information, but does not disturb people’s routine too much. After all, now the home is the company and the company is the home. Gather your team and wake up that time. Set a time for work, even if reduced, but where everyone can interact at will. Set kind intervals for meals so that you can serve different homes. This will decrease your team’s anxiety and allow everyone to better organize their lives.

Create common environments

Some companies make their employees all connect from the beginning to the end of the workday using a communication tool. Sometimes even using video. This can end up being a little over, and give a feeling of mistrust and a very bad attempt at control for everyone. If some feel uncomfortable in this way, and this sparks a controversy that can range from the design of the Panopticon to the Hawtorne effect, some alternatives can be tried.

Common working and decompression environments can help. Some companies have adopted some solutions in this regard, such as:

• Creation of a common work room, without mandatory connection, simply providing a virtual space that people can use when they find it interesting;
• Holding a daily meeting, like Scrum, in a virtual room common to all. This gives the opportunity for people to participate in a brief interaction, to arrange subsequent virtual meetings if necessary, and to coordinate their efforts, without making the meeting somewhat invasive, given its brevity;
• Creation of a virtual cafe room, where team members connect when they want to have a coffee and relax a little. This tries to replace the “coffee”, so common in our work environment, where different subjects are discussed.

Provide the necessary equipment and tools

Not everyone on your team has the right resources to work from home. Some need a better chair, others need a camera, some even need a table or a better Internet connection. Check with your team what they lack for remote work and take the necessary steps. For many companies the cost of maintaining traditional workplaces has been greatly reduced, allowing for greater support for their teams. Additionally, individuals started to have costs that they eventually did not have. The company being able, should help. If you can’t, talk to the team and make arrangements.

In this new scenario, some tools can help a lot in coordination and organization. ScrumHalf, for example, has all the resources to support remote work, from Backlog, Virtual Kanban Board, facilities to conduct Review and Retrospective meetings, resources to plan delivery remotely, and even chat rooms restricted to projects – War Rooms – for team interaction and record conversations. Remote work ends up requiring greater documentation of decisions and resources like this can make your team’s life much easier. Additional communication software, especially videoconferencing, will certainly be needed.

Attention to Documentation

The team interaction will now be a little more chaotic, even though you have taken some precautions as described above. As seen, people are not always fully available during their working hours and the absence of some information can create an unnecessary impediment. The best thing about this new reality is to pay a little more attention to the documentation, always remembering that someone else on the team may need to work on what you are working on now. Always ask yourself what you would need to know if you were to work on that task without knowing the problem deeply. What information would you need? Were they registered somewhere already? If positive, indicate. If not, record them.

Prioritize Technical Stories

Of course, you are building a product or performing a service for your customer and you need to deliver tangible value to them. But we all know that any project ends up accumulating technical stories, that even though they are not directly perceived by the client, they are also producing value for him. If possible and will not compromise the deliverables to be made, try to put technical stories in front. At least until your team feels more comfortable with remote work and remote interaction with the customer. Technical stories demand less interaction and can even help the team to gain confidence in the new work model.

Be Present for Your Team

Make it clear to your team that you are always ready to help them. Regardless of the agreed times, agree that if there is an emergency or something that really hinders the progress of the work, and that you can help resolve it in some way, the agreement can be broken and you can be called.

If necessary, establish a color code in the agreement. In green time the call is free, in yellow only if there is a significant impact on the result and in red only if it is an emergency. Give an example of each case, to help your group understand how to behave. It is important for everyone to know that there is support and that the fact that they are physically isolated does not mean that they are loose and need to solve everything without help from anyone.

The reality we live in demands resilience and creativity. More than maintaining the productivity of our team, we must contribute to their well-being and satisfaction. It is in a time of difficulties that the real opportunities are revealed. Take this opportunity to improve the quality of life at work, even if it is remote. Your help and interest can make all the difference with your team.

And you who are already remote, what practice do you use to make this remote work pleasant and interesting? Tell us in the comments.

*Translated by Google

The post Remote Work – 7 Tips to Help Your Team * appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

É evidente que nem todo atraso na realização de tarefas, ou falhas de entrega do time ao final da Sprint, pode ser remediado. Entretanto, esses problemas nunca devem passar despercebidos e o Burndown é um grande auxílio nesse aspecto, sinalizando que algo pode não estar indo como previsto. Ele serve como uma alerta, para que o time analise o quadro atual e o que será necessário fazer para entregar o combinado, ou até para adicionar novas atividades, entregando mais do que o combinado.

No entanto, infelizmente, muitas vezes esse gráfico tão simples e útil, é mal empregado e acaba trazendo prejuízos ao invés de benefícios para o time. Vamos dar uma olhada nos 3 principais vícios na utilização do gráfico de Burndown.

Controlar o Time

Não é vigiando o Burndown para avaliar o trabalho do time que as coisas vão mudar. Na verdade, esse tipo de atitude atrapalha muito o funcionamento da agilidade. Na agilidade todos trabalham com comprometimento absoluto. As pessoas são empoderadas para resolverem problemas e atuarem da melhor forma possível.  O controle indevido acaba se tornando um estopim para o início de uma crise na equipe. Acaba gerando contrariedade entre PO e time, com acusações mútuas que podem desencadear crises muito mais sérias. O gráfico de Burndown não deve ser utilizado com uma ferramenta para exercer o Comando e Controle.

Comparar Times

O Burndown também não é ferramenta para comparar times. Aliás, na Cultura Ágil, a preocupação deve ser muito maior em motivar do que comparar desempenho. O objetivo não é dar “pressão” no time, mas trabalhar junto com o time, buscando pontos de melhoria, para cada vez mais aumentar a eficácia e eficiência. O próprio sistema de pontuação de histórias, velocidade, e planning poker, utilizados na maioria dos times Scrum, não permite comparações entre equipes. É um sistema de pontuação sem uma referência única, onde cada time estabelece suas referências e seus valores de acordo com as suas percepções e capacidades, dentro de seus respectivos cenários. A utilização do Burndown para comparação de times além de inapropriada e sem nexo, é improdutiva.

Medir Performance

A performance do time de forma ampla é avaliada pelo cumprimento do combinado. Isso de uma forma geral acaba sendo feito conjuntamente durante a Retrospectiva, em função do resultado da Revisão. Acontece que, em alguns casos, membros do time, ou mesmo participantes externos, acham que podem utilizar o Burndown para avaliar o desempenho do time durante a Sprint. Ficar medindo performance através de indicadores como o Burndown, além de não ser adequado, cria um clima de desconfiança prejudicial, e acaba levando ao primeiro vício que citamos, o de tentar controlar o time, utilizando o modelo de Comando e Controle.

É importante que todos os envolvidos com o Scrum entendam que o Burndown é um mecanismos de transparência, de awareness, e não uma ferramenta de medição de desempenho para uso numa estrutura de Comando e Controle. O propósito do Burndown é dar visibilidade à evolução dos trabalhos, para permitir que o time faça a devida análise do mesmo, considerando o cenário e o momento que se encontram. Existem outras métricas bem interessantes que podem ajudar o time. Entretanto o Burndown deve, e precisa, ser usado de forma útil e frequente para ajudar o time a dar o seu melhor.

Como vocês estão usando o Burndown no seu time? O Burndown tem ajudado? Conta para a gente.

The post Burndown Chart – As 3 Principais Confusões appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The idea with planning in a general way is to allow us to prepare for the future, especially with regard to making decisions that promote the effectiveness and efficiency of our project. In this article Planning a Sprint: Velocity and Estimation, eg, we talk about Sprint planning.

However, in addition, we should also understand that the process of estimating involves the search for knowledge about what one wants to estimate. In development projects, be it software or any other product or service, this means discussing the subject with the client / user. Search and investigate similar products or services or competitors. Often even promote discussions with experts. And this search for knowledge brings as a side effect a better understanding of what one wants to estimate. The more we know the more we agree, as we discussed in this post Well written Stories, more accurate estimations.

So, we come to the first important aspect, addressed in a way by #noestimates. We should only estimate if this is necessary for something that brings us value. Whether it is to forecast costs, deadlines, plan capacity, define project scope, understand dependencies between requirements and / or improve understanding about something we should do.

On the other hand, we know that estimates are inherently inaccurate, especially if wrong time. The literature related to software projects makes this very clear, as presented by Robert Glass, Here summarized:

1. Most software estimates are made early in the life cycle when there is little understanding of the problem.
2. Most of estimates is made by management or by marketing, not by who will actually build the software.
3. Rarely estimates are redone.

Considering such observations, we can also deduce for which estimates should not be used.

1. Determine something accurately.
2. Set challenges.
3. Reward performance.
4. Cure lack of commitment.
5. Establish confidence.

We know that estimates are often misused and need to be addressed. But estimates are an indispensable part of a planning process which, as we have seen above, serves at least to organize efforts towards the attainment of some objective.

How then? We tell the client that it is impossible to plan because we can not or should not estimate anything? Do we plan in detail all that we are going to do?

Well, we must first understand that the Agile movement perceived this problem in traditional development processes and established some policies that help reduce the negative side effects of estimates. I highlight the most related, in my view, the estimates: “Respond to changes rather than following a plan.” This means, for example, that in planning something we understand that our knowledge of what is planned will change and that we will need to review our planning. Everything to do with what we discussed above.

In general, the #noestimates movement, or the recommendations of it, follows the same path of many others that have arisen in agility: it brings several interesting insights, but it can not be applied in any way absolute or in any case.

Many projects and organizations with which we have contact already, in a way, when using Scrum, work with #noestimates. For the most part, teams estimate stories using story points. However, most do not estimate tasks by simply setting a timebox for them. It is common for teams to break their stories into tasks by limiting the size of their tasks so that they can be accomplished in a day, at most by two.

In conclusion, #noestimates is very valid, but does not mean that it should or can not be applied indiscriminately. If you add value, estimate is accurate. The most important thing to remember is that estimating by estimating only disrupts the team.

How has your experience in Scrum projects been? Does your team estimate it or not? Do you see value in estimating?

The post Estimate ou #NoEstimates? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Todos os desenvolvedores de software possuem um mesmo objetivo: Entregar software com valor, rápido e com baixo custo. Esse é um objetivo aparentemente simples, mas que tira o sono da indústria e academia há décadas. Correndo atrás desse sonho está a área da Engenharia de Software, buscando oferecer ferramentas, práticas e estudos para que o desenvolvimento e manutenção dos produtos sejam mais eficientes. Mas já parou para pensar em quantas técnicas, padrões, frameworks etc. existem? Incontáveis soluções são oferecidas e devem ser adequadas a cada um dos casos. Independentemente das práticas utilizadas, uma pergunta tem que estar em mente o tempo todo: Como anda a engenharia de software do meu projeto? E, para responder essa pergunta, foi criado o SEMAT.

O SEMAT (Software Engineering Method and Theory) foi fundado em 2009 para ajudar a resolver diversos problemas que a indústria vem enfrentando. Seu primeiro passo foi fornecer uma fundação (chamada de Kernel) que irá suportar todo o pensamento de software daqui em diante, independentemente das práticas e ferramentas utilizadas. Com esse kernel, é possível entender se o processo, seja ele ágil, cascata ou qualquer outro, está atendendo as áreas consideradas pelo grupo como essenciais: Os chamados Alphas. Esses Alphas são divididos em temas e se relacionam entre si das mais variadas formas, como podemos ver na figura a seguir.

Mais informações sobre o modelo, os estados e os Alphas podem ser obtidas no guia de referência, mas farei uma breve descrição de cada um deles a seguir:

Cliente:

Área que se preocupa em saber se o time entende os stakeholders e a oportunidade que está sendo endereçada

• Oportunidade: As circunstâncias que fazem apropriado a criação ou alteração do sistema em questão.
• Stakeholders: As pessoas, grupos ou organizações que afetam ou são afetadas pelo sistema.

Solução:

Área que se preocupa  em saber se o time estabeleceu um entendimento conjunto dos requisitos e implementou um sistema capaz de atender os mesmos.

• Requisitos: As restrições que o sistema deve atender para endereçar a oportunidade e satisfazer os stakeholders
• Sistema de Software: O sistema como um todo, composto de software, hardware e dados

Endeavor (Traduzido livremente para esforço):

Área que se preocupa com o time, sua maneira de trabalhar e com o trabalho a ser feito.

• Trabalho: As atividades envolvendo esforço (mental ou físico) com objetivo de alcançar o objetivo
• Time: O grupo de pessoas engajado no desenvolvimento, suporte e gerência do projeto
• Maneira de Trabalhar: O conjunto de práticas selecionado que guiará o time e ajudará no trabalho

Cada um desses alphas possuem um estado a ser determinado pela equipe, utilizando a técnica denominada de Progress Poker. Esse método foi criado para ser rápido de ser executado e prover valiosa informação sobre o projeto de uma forma geral. O objetivo é que a equipe avalie cada Alpha, os estados que o mesmo possuem e entre em um consenso da situação atual naquele quesito.

É importante avaliar os itens que não foram atendidos porque são eles os pontos a serem atacados para a melhoria do processo.

Para verificar na prática essa técnica, utilizamos em um dos nossos projetos e obtivemos o seguinte resultado:

Como podemos ver, estamos bem posicionados em relação a Cliente (Oportunidade e Stakeholders) e Solução (Requisitos e Sistema de Software) mas pecando um pouco na área de Esforço (Time, Trabalho e Maneira de Trabalhar).

Sabemos que a causa dessa situação se deu pela entrada de diversos membros novos na equipe que ainda não haviam internalizado as práticas e atividades que a empresa executa. Esse foi o foco de maior trabalho para que o cenário identificado fosse revertido.

Em relação as outras duas áreas, é satisfatório perceber que bons resultados estão sendo obtidos e as práticas adotadas continuam sendo mantidas.

Faça você também a avaliação do seu projeto e deixe um comentário com a sua impressão!

The post (Português) SEMAT – Como Anda a Engenharia de Software do Seu Projeto? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Nos últimos anos, na área de TI, muito tem se ouvido falar em DevOps.

Esta cultura tem tornado cada vez menos rígida a fronteira entre o desenvolvimento e as operações de TI necessárias para manter os sistemas no ar.

Diante dos muitos benefícios trazidos pela adoção das práticas de DevOps, principalmente em times ágeis, quais seriam as razões para que esta cultura tenha ganhado força somente num passado recente? Que fatores motivam as práticas de DevOps? Que fatores permitiram que o DevOps se tornasse uma realidade?

No post de hoje vamos elicitar 3 grandes motivadores da cultura DevOps na atualidade.

O conflito histórico entre equipe de infra e equipe de desenvolvimento parece estar com os dias contados. As práticas de DevOps vem com o objetivo de facilitar a integração entre atividades de desenvolvimento, como criar novas features, resolver bugs, etc, e as operações de infra para manter o sistema no ar como manutenção dos servidores, sincronização e deploy do código, etc.

Realizar estes dois tipos de tarefas de forma coordenada pode trazer diversos benefícios através da colaboração entre os profissionais que criam e testam as aplicações e as equipes que mantém todo o ambiente de produção no ar. Para mais informações sobre DevOps, leio o post "Já Ouviu Falar em DevOps?".

Como falei no início do post, os processos de DevOps começaram a marcar presença mais fortemente nos times de TI somente nos últimos anos. Principalmente pela constante necessidade de mudanças e, consequentemente, pela maior necessidade de agilidade nas entregas, o cenário que encontrado em muitos times de desenvolvimento praticamente "pedia" a aplicação dos processos de DevOps.

Entender os motivos que levaram a ascensão destas práticas pode ajudar na aplicação das mesmas de forma a extrair o máximo dos benefícios trazidos com as técnicas de DevOps. Abaixo, enumeramos 3 grandes fatores que ajudam a entender o porquê da adoção e valorização das práticas de DevOps atualmente:

1. Cultura Ágil

Dentre tantas melhorias, como os avanços nos meios nos setores de telecomunicação e tecnologia da informação tornaram a realidade das organizações cada vez mais dinâmicas.

Com ambientes mais dinâmicos surge a necessidade de maior flexibilidade e respostas mais rápidas às mudanças. Mais especificamente na área de TI, é preciso que os sistemas sejam desenvolvidos e mantidos de maneira que mudanças possam ser aplicadas com agilidade.

É necessário estar continuamente entregando valor. Para que isso seja possível é preciso que, uma vez desenvolvido, um sistema possa ir para produção rapidamente e com qualidade. Um gargalo que pode ser comumente encontrado é na burocracia muitas vezes imposta pelas equipes que mantém os sistemas no ar. Para estas equipes, a priori, mudanças não são bem vindas e estão sempre associadas a riscos. Porém, para o negócio as mudanças tem se tornado cada vez mais necessárias.

O tempo entre o desenvolvimento de um recurso e o deploy em produção pode ser um fator determinante para o sucesso ou fracasso de uma iniciativa de uma organização. Diante deste cenário é possível notar os processos de DevOps surgem como uma prática interessante na medida em que permitem que as mudanças sejam levadas rapidamente para produção de forma coordenada e com qualidade, reduzindo o time to market.

As práticas de DevOps tratam de tornar mais eficientes e, quando possível, automatizar todas as operações necessárias para que um código saia do desenvolvimento e chegue em produção com rapidez e qualidade, que é o que se pretende dentro da cultura ágil.

2. Tecnologia

Operações como realizar deploy de forma bem controlada, gerar de pacotes, executar testes, automatizar scripts para sincronização de pacotes, dentre outras operações não são desejos recentes na TI.

Antes mesmo do crescimento da cultura ágil e da necessidade de entregas contínuas, a automatização de operações de TI já era um desejo em muitos times. Podemos nos perguntar: Então por que estas operações ganharam maior atenção agora com as práticas de DevOps?

O primeiro ponto que me vem em mente é o fator financeiro. Antigamente, responder rápido a mudanças era algo não tão "lucrativo" quanto hoje. Primeiro porque o custo para automatizar estas operações era mais alto.

Segundo, por que a necessidade por respostas rápidas a mudanças não era tão grande quanto hoje.

Outro ponto é a tecnologia. Atualmente com a virtualização e computação na nuvem, além da alta capacidade de processamento das máquinas, ficou facilitada a construção de ferramentas voltadas para o apoio às operações de TI, como automatização de testes e gerência de configuração,por exemplo. Além disso, os crescentes investimentos em aplicativos para dispositivos móveis tem impulsionado criações e atualizações que precisam ser lançados frequentemente com agilidade e qualidade.

3. Infra estrutura mais complexa

Manter os sistemas de uma organização no ar tem se tornado uma tarefa cada vez mais complexa. Atualmente, muitas são as formas de disponibilizar as aplicações no ar. A manutenção, que antes era feita somente sobre as máquinas físicas, hoje é feita sobre máquinas físicas, máquinas virtuais, além da nuvem.

Estes novos recursos permitem que as equipes responsáveis por manter os sistemas no ar tenham maior previsibilidade, garantias e SLA bem definidos na manutenção de seus sistemas.

Por outro lado, a complexidade decorrente destes serviços requer que as operações de TI estejam bem definidas e automatizadas na medida do possível, para garantir que os benefícios alcançados com estes serviços sejam alcançados.

A partir destes 3 grandes fatores fica fácil perceber a necessidade e os benefícios que o DevOps pode trazer às organizações atuais.

Para o desenvolvimento ágil é importante que as operações sejam feitas com a colaboração de todo o time, conferindo mais rapidez nas entregas, e economizando nas burocracias.

Métricas importantes como o Time to market são afetadas diretamente com a implantação das práticas de DevOps, que pode reduzir significativamente o tempo necessário para que um produto seja disponibilizado no mercado.

The post (Português) 3 Motivadores para a Cultura DevOps appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.