A Elixir Radar, nossa newsletter semanal dedicada a promover conteúdos relevantes e oportunidades de trabalhar com Elixir em empresas de todo o mundo, se tornou um de canal de grande importância para nós. Com mais de 100 edições, aprendemos muito sobre como podemos trazer mais valor para a comunidade.

Com esse aprendizado, decidimos tomar mais um passo para a melhorar a experiência de todos que nos acompanham nos nossos canais e redes sociais: vamos criar uma conta no Twitter da Plataformatec Brasil.

Nesse canal você pode seguir nossos conteúdos em português sobre temas de tecnologia, software e ágil. Além de acompanhar a participação do nosso time em eventos e conhecer um pouco mais sobre a cultura da Plataformatec.

The post Lançamento do Twitter da Plataformatec Brasil first appeared on Plataformatec Blog.

Well, those are all good points. Really. However, all of those are remediable. Nowadays you cannot say that distributed teams don’t work. You need to make it work! That is the reality of the world.

But enough of whys, let’s get to how. How can we remediate all those problems? Or even avoid them? How can we be agile without ever seeing each other?

Communicate, talk, say, share!

The first thing that you need to think about when working with distributed teams is communication. And since it is already difficult to improve it in a colocated team, you may imagine that the difficulty adjusting it in a distributed team is even higher, right? Not necessarily, actually. Those are different environments, with different challenges. And this difference is the key.

If you try to adapt what you do in a colocated team to use it in a distributed one, you’ll likely fail. Things like talking to someone at their desk is not the same as a private message on a channel, for example. In the first example, other people can hear you and enter the conversation if needed. A private message is like going to a sound-proof room with your colleague and talking about something. Therefore, keep an open mind and try new things. Below I list four things that you could change to improve your communication.

No more poking

Zach Holman calls that “remote first”. The idea is that you need to prioritize the use of asynchronous communication tools when in a distributed team. That means that those poking-and-talking meetings will be converted into written discussions, or video conferences, using your preferred communication tool.

“Oh, but we already use Slack!”

It is not about using it; it is prioritizing its use. And that is extremely difficult. Let’s say that you have five people on site and two offshore. Those onsite need to communicate every minimally important thing through the communication tool, with the preference for open channels and not private chats. Otherwise, you’ll develop an information silo, will decrease trust between people from different locations, etc.

Online meetings? Really?

Ceremonies and meetings are usually a dreadful experience when online, and there’s not much we can do about that… After all, the internet connection fails, you need to repeat everything ten times, the audio quality is never perfect, and it is just annoying to not interact with people.

However, there are some things that you can do to improve that experience. You need to have the right tools, and a clear goal for the meeting, you’ll find more on that in this blog post.

Besides that, each person should preferably be in their own machine, even if you have some people together in the same building. In my experience, people that are together in a room tend to share information while the microphone is muted. However, that information could be useful to the offshore team.

But one thing that I want to demystify is the necessity of meetings.

Please, only have meetings if you need them! And that is something to consider even in a colocated team. Most people start working with Scrum, Kanban or whatever methodology that comes with their set of necessary ceremonies. You need to think, and re-think, all the meetings objectives and check if they are necessary for your context. And if they are, check if all invited people are required. Don’t waste people’s time with unnecessary meetings.

But I’m in LA and she is in China!

If you have distributed teams in just one time zone, you are a lucky one. However, people usually have distributed teams across the entire world, going from 1 to sometimes 12 hours of difference. And each team needs to adapt their process to make sure that everyone receives the same information and participates in decisions over the future of the project.

The important point here is to stay as a team and try to have at least part of the day (or of the week if the time zones are too different), like an hour, that everyone is online. With that synchronized time you can put everyone on the same page.

Fly!

You’ll need to meet in person eventually. Not frequently though. Once a month, or even once a year, might be good enough. The idea of this encounter is to humanize people since we will often only interact with faces and texts on screen. That improves trust among everyone and brings the team back together. Think of it as a reset for group relationship. Bringing everyone together will relieve stress and improve interactions.

Different places, different cultures

Culture is a crucial point to consider when having distributed teams. We often expect people to behave as similarly as we would in the same circumstances, and it can break our expectations, hence, causing stress. I’ll detail two points that I often face in distributed teams that could help you.

Can I invite everyone to Carnival?

Whether you are hiring someone that will work remotely or are entering a team that has people from other countries, you need first to understand the countries’ differences. I’d suggest a comprehensive analysis of the country’s culture, how people usually behave when facing difficulties, how they say things (if directly or indirectly), what are their working times and related subjects. With all that information, you can manage your expectations and change your actions accordingly.

Hola, how você esta?

That is a very tough subject to address. What if you are working with team members that don’t speak the same language? Well, we’ve been there, and the answer is pretty simple: you need to communicate somehow, and it doesn’t matter how. Sometimes we opt for a common language, Esperanto most of the time (just kidding), and sometimes we try to learn the other person’s language if it is possible, like Spanish. But it doesn’t matter if you speak English, Latin or whatever. What is important is that, at the end of the day, you understood each other.

Just give them this bunch of tasks!

Especially when you have part of a team distributed in another region, it is common to have them as a “black-box team.” It is important to avoid scenarios in which you select demands for that team, instead of having the stories being pulled by whoever is free at the time. It is better not to have this kind of differentiation.

Ok, but what tools should I use?!

Before surrendering yourself to products that claim to be the silver-bullet for distributed teams, think about your process and how you can improve it. Then, if you need a tool, you’ll know what to search for.

However, if you want to know some of the tools you may need, we have an already extensive guide in this blog post. To make it easier for you, I’ll just mention some of the tools we use.

• A video conference tool, like Hangouts with a microphone handler like Shoosh
• An asynchronous conversation tool, like Slack
• A place to put findings and documents, like Google Drive and/or Basecamp
• A wiki like Confluence may also be useful
• For your Kanban board, you may use something simpler like Trello or something with more options (but less customizable), like Jira.

Conclusion

The takeaway from this post is to improve communication and have empathy to understand the other. It is all about the process, not the tools you use.

I presented a huge number of things to do in a distributed team. Ergo, if you are seeking perfection you would need all of them, but to be better than yesterday, you just need to implement one at a time.

Do you agree with our approach? Leave your thoughts below!

The post How to work with distributed teams first appeared on Plataformatec Blog.

Your product starts to get fancier, and your clients begin to subscribe… That is just amazing! However, your team is feeling a little unmotivated. You start participating on their retrospectives to check how you can help and you see a pattern: people are complaining, in other words, the Agile Specialist is micromanaging everyone.

You decide to closely follow the team during a month, investigating what are the things happening there that are discouraging them. Suddenly, you see yourself in a daily meeting, in which everyone talks about what they did and what they’ll do. Soon enough you spot the problem: they are using the daily meeting to report work instead of spreading knowledge and removing blocks. But what now? How to achieve those goals without the reporting feeling?

The feeling of a micromanaging daily ceremony always caught me while working in the industry as a developer. I always thought people wanted me to report what I was doing, with the intention of knowing exactly how efficient I was. That caused different kinds of behaviors, the most common was to do more things at once, to show I was working more.

However, doing more tasks at the same time might slow everything down, make your work less valuable and affect the rest of the team. More on that subject can be found in these blog posts:
* Case Study of a WIP Limit Implementation: Why, When and How to use WIP Limits
* The Hero Syndrome and how to deal with it

Therefore, to overcome that situation, we at Plataformatec started using a different approach in the daily meeting. We saw that the problem of the “old way” was that teams were focusing on what each person did instead of on the progress of the project itself. With that in mind, we just changed the focus. Instead of asking people what they did, we started asking cards.

No, we are not going mad (I guess)… And of course, we didn’t talk to a post-it either (even though talking to inanimate objects may help on development, like rubber ducks). However, we changed the way we asked things. Here is how we do it:

We go over the board, from right to left, asking the whole team how is each card’s development:

• How is its development? Any technical difficulties?
• Is there anything blocking its development?

You may say that it is not that different from what a usual Daily Meeting looks like. However, let me point out the differences and their importance:

• We look at the cards on the board, from right to left. By looking at the card further in the process, we are looking at the feature that will most likely bring value in the short term.

• The questions are directed to the team, not to a person. Asking the whole team about a card brings back the team sense that we lose asking individuals. It shows that we don’t care about who is working on it, and how much. We care about that project’s development.

• The questions’ subject is not “you” anymore, it is “it”. We used to ask things like “What have you done the past day? What are the blocks that you had?” etc. By changing the subject, you reinforce that the focus is on the feature development, and you also make the team talk only about what is important to the project, and not about peripheral topics.

• Extra: We simply look more at the board. Yes, that simple. You probably experienced that, with time, people start to not spend as much time as they did at the beginning of the project looking at the board. The simple fact that we are using it to run the ceremony, brings attention to it and we can easily spot when someone is overworking, when a card has been at the same column for too long or other related issues.

Conclusion

What we suggest here is not a big change, actually, is pretty subtle. Instead of focusing on what people did, focus on what is being developed. You’ll see great improvements in people’s feelings, everyone will be in touch with the process everyday through the board and, as the famous Lean quote states, people will stop starting tasks and start finishing them.

What do you think? Would you use this method? Leave your comments below!

The post Bringing continuous improvements into your agile process: A different Daily Meeting first appeared on Plataformatec Blog.

Seu produto começa a ficar mais robusto, e seus clientes começam a aderir a ideia… Incrível! No entanto, seu time está se sentindo um pouco desmotivado. Você começa a participar de suas retrospectivas para checar como poderia ajudar, e observa um padrão: as pessoas estão reclamando, com outras palavras, que o Especialista Ágil está micro-gerenciando a todos.

Você decide acompanhar de perto o time durante um mês, observando o que está ocorrendo em relação a isso. De repente você se vê em uma Daily Meeting, na qual todos falam sobre o que fizeram e o que farão. Você então vê o problema: eles estão usando o Daily para reportar trabalho, ao invés de pulverizar conhecimento e remover bloqueios. Mas e agora? Como conseguir estes objetivos sem a sensação de reporte?

O sentimento de um Daily micro-gerenciador sempre me acompanhou quando trabalhava como desenvolvedor. Eu sempre pensei que pessoas queriam que eu reportasse o que estava fazendo, com a intenção de saber exatamente o quão eficiente eu era. Isso causava diferentes tipos de comportamento, o mais comum era fazer mais coisas ao mesmo tempo, para mostrar que estava trabalhando mais.

No entanto, fazer mais tarefas ao mesmo tempo pode trazer lentidão ao processo, tirar valor do que você está fazendo e afetar o resto do time. Mais sobre esse assunto pode ser encontrado nestes blog posts:
* Case Study of a WIP Limit Implementation: Why, When and How to use WIP Limits
* A síndrome do herói e como lidar com ela

Portanto, para superar essa situação, nós da Plataformatec começamos a usar uma abordagem diferente em nossos Dailies. Nós vimos que o problema do “método antigo” era que os times focavam no que cada pessoa fazia ao invés de focar no progresso do projeto. Com isso em mente, mudamos o foco. Ao invés de perguntar às pessoas o que fizeram, passamos a perguntar às histórias.

Não, não estamos ficando loucos (eu acho)… E obviamente não estamos conversando com post-its (apesar de que falar com objetos inanimados pode ajudar no desenvolvimento, como patos de borracha). No entanto, mudamos como perguntamos as coisas. Aqui está nossa versão:

Começamos olhando o kanban, da direita para a esquerda, perguntando ao time todo como está o desenvolvimento de cada história:

• Como está seu desenvolvimento? Alguma dificuldade técnica?
• Existe algum bloqueio para o seu desenvolvimento?

Você pode achar que não é tão diferente do Daily usual. No entanto, deixe-me pontuar aqui as diferenças e suas importâncias:

• Nós olhamos para as histórias no quadro da direita para esquerda. Olhar a história mais a frente no processo nos faz olhar para o que provavelmente nos trará mais valor em um curto período de tempo.

• As questões são agora direcionadas ao time, não à uma pessoa. Perguntar ao time todo sobre uma história traz de volta o sentimento de time, que perdemos quando fazemos perguntas individuais. Mostra que nós não nos importamos com o que cada um está trabalhando, e quanto. Nos importamos com o desenvolvimento do projeto.

• O sujeito das perguntas não é mais “Você”, e sim a história. Costumávamos a perguntar coisas como “O que você fez ontem? Algo está te bloqueando?” e etc. Mudando o sujeito da pergunta, reforçamos o foco no desenvolvimento da história, e também fazemos o time conversar apenas sobre o que é importante ao projeto, e não sobre tópicos periféricos.

• Extra: Nós simplesmente olhamos mais para o quadro. Sim, tão simples quanto isso. Você provavelmente já viu que, com o tempo, as pessoas começam a não olhar mais para o quadro como inicialmente. O simples fato de usá-lo como base da cerimônia, traz atenção a ele, fazendo com que possamos facilmente ver quando alguém está trabalhando em excesso, quando uma história está parada na mesma coluna por muito tempo ou outros problemas relacionados.

Conclusão

O que sugerimos aqui não é uma mudança grande, na verdade é bem discreta. Ao invés de focar nas pessoas, foque no que está sendo desenvolvido. Você verá grandes melhoras no sentimento das pessoas, todos estarão em contato diário com o processo através do quadro e, como a famosa citação do Lean diz, as pessoas vão parar de começar tarefas e começar a terminá-las.

O que achou? Você utilizaria este método? Deixe seus comentários abaixo!

The post Desenvolvendo melhoria contínua em seu processo ágil: Um Daily Meeting diferente first appeared on Plataformatec Blog.

Como vocês devem ter percebido, nos últimos anos a Plataformatec tem investido cada vez mais na área de processos. A quantidade de conteúdo sobre agilidade que produzimos em 2016 foi superior ao que fizemos em todos os anos anteriores somados!

No entanto, temos muito mais a falar do que conseguimos escrever… Temos muitos assuntos interessantes, abordados no contato diário com nossos clientes, e sentimos que precisamos compartilhar ainda mais as novidades que presenciamos. Com isso, veio a ideia da newsletter mensal de agilidade!

O propósito da newsletter é compartilhar com vocês blog-posts, artigos e conteúdo em geral que nos impulsionam e nos ajudam a superar os desafios que encontramos no dia-a-dia.

Ah eu sou dev, o que isso agregará para mim?

Tenha você um papel de Dev, Product Owner, Gerente de Projetos, Scrum Master, CTO, CEO ou qualquer outro relacionado a tecnologia, essa newsletter é para você. Para você que quer desenvolver softwares melhores de maneira mais ágil. Para você que precisa priorizar melhor as features do seu produto, para gerar valor mais rápido para sua empresa. Pra você que precisa de mais ferramentas para engajar o time e fazer com que a cadência de entrega seja mantida. Seja qual for o seu cargo, se você tem tecnologia no coração e agilidade na veia, essa newsletter é para você.

Mas Colucci, o conteúdo será sobre Scrum? Kanban? XP?

Bom, como dissemos em nosso blog post “Nós não somos necessariamente Ágeis… Mas com certeza somos ágeis!“, nós consideramos que o futuro do ágil não está em seguir uma ou outra metodologia, e sim adaptar ao seu contexto as práticas que impulsionem seu processo de desenvolvimento. Com isso, não vamos nos prender à metodologias na hora de compartilhar tais conteúdos. Vamos focar em apresentar conteúdo de qualidade, seja de XP, Scrum, Kanban, PMBOK ou outra vertente.

Então será apenas uma curadoria de conteúdo? Por que não uso o Google?

Google, e afins, são ótimas fontes de informações (acredito que sem Google, Stackoverflow e Wikipedia o mundo ainda estaria dependendo de máquinas a vapor), mas para usá-los você precisa saber o que não sabe. A nossa intenção é apresentar conteúdos que você não sabia que precisava, trazer um grau de serendipidade à newsletter.

No entanto, não é apenas uma curadoria de conteúdo. Em cada edição, um de nossos Agile Consultants vai desenvolver sua análise, opinião e visão acerca de um tema Ágil, baseando-se na experiência da Plataformatec de 8 anos entregando projetos de software e prestando consultoria sobre agile.

Mas eu não quero minha caixa de entrada do email lotada!

E nem terá! A nossa newsletter será mensal! Entre um mês e outro você terá tempo de sobra para amadurecer o conteúdo compartilhado.

E quanto isso vai me custar?

Nada. Zero. “De gratis”. “0800”.

Como me inscrevo?!

Se você se interessou e deseja se inscrever, basta entrar no link da ContÁgil e colocar seu email. Fácil, rápido e indolor.

The post ContÁgil: A nossa nova newsletter mensal de agilidade first appeared on Plataformatec Blog.

Atenção desenvolvedoras e desenvolvedores, tenho uma ótima notícia. Estamos com vagas abertas na Plataformatec!

Não estamos procurando “ninjas” ou “rockstars”. Procuramos pessoas responsáveis, que busquem sempre melhorar suas habilidades em desenvolvimento e gostem de trabalhar com autonomia.

Para fazer parte do nosso time, você precisará ser aprovado em nosso processo seletivo. Hoje ele é composto por 5 etapas:

No Bate papo inicial, o objetivo é conhecermos melhor os candidatos e apresentarmos quem nós somos; a Entrevista técnica tem por meta avaliar o conhecimento sobre desenvolvimento web (em especial, utilizando Ruby e Rails); já na etapa de Show me the code queremos ver seu código; no Pair programming avaliamos como os candidatos pensam e se portam ao escreverem seu código. E finalmente, com todas essas informações em mãos, conseguimos fazer a Proposta financeira.

O objetivo desse post é dar dicas sobre como ir bem na terceira etapa. Como já mencionado, a etapa Show me the code é o momento que as candidatas ou os candidatos têm para demonstrarem na prática o conhecimento avaliado durante a Entrevista técnica. A pessoa precisará desenvolver um aplicativo web de escopo reduzido que deve ser feito no prazo de uma semana.

Depois de entregue, o aplicativo será revisado por nosso time que buscará as boas práticas de desenvolvimento.

Vou citar algumas dicas que podem te ajudar a escrever um código com mais confiança e atingir um bom resultado:

• Familiarize-se com a ferramenta
• Comunique-se
• Reflita sobre a segurança
• Busque a simplicidade
• Valorize seu frontend
• Dê atenção a usabilidade

Familiarize-se com a ferramenta

Somos uma consultoria de Ruby e Ruby On Rails e esperamos que o candidato tenha familiaridade com a tecnologia. Mesmo que você venha de outra linguagem, esperamos que você saiba desenvolver usando as funcionalidades mais comuns do framework. Recomendo ler Ruby On Rails Guides e fazer o tutorial do livro online Ruby On Rails Tutorial.

Comunique-se

Comunicação é muito importante para o nosso time. Durante o desenvolvimento, pense nas pessoas que vão revisar seu aplicativo e testá-lo. Pense nelas como se elas estivessem trabalhando junto com você. Valorize suas mensagens de commit, diga o quê e o porquê das mudanças. Uma boa ferramenta de consulta é o GitHub, inspire-se em projetos open source que você gosta.

Reflita sobre a segurança

Um app seguro é essencial para os usuários e conta como pontos positivos. Dê uma lida no guide sobre segurança do Ruby on Rails e certifique-se se as actions do seu controller estão com as permissões corretas.

Busque a simplicidade

Sabemos que o tempo para produzir o código para nossa revisão é curto, mas o escopo também não é grande. Portanto, tente não se complicar adicionando muita complexidade. Não deixe de mostrar seus pontos fortes, porém o faça de maneira simples. Por exemplo, se você não domina muito Javascript, não precisa fazer uma single page app, com um framework grande de frontend, integrado com backend Rails conectado em diversos microserviços. Faça o simples que vai dar tudo certo.

Valorize seu frontend

Nosso foco é desenvolvimento web, portanto conhecimento de HTML, CSS e Javascript são muito importantes. Esperamos que o mesmo carinho que você tem no seu código Ruby tenha também no seu código de frontend.

Se você manja de HTML e CSS, aproveite essa chance. Como muitas pessoas acabam escolhendo utilizar Bootstrap, essa é a oportunidade de mostrar seu diferencial.

Dê atenção a Usabilidade

Pense nos usuários que vão usar o aplicativo que você fez. Como a pessoa irá navegar e fazer as tarefas? Está intuitivo? É bom repassar os fluxos da aplicação manualmente para ter certeza de que as pessoas que usarem o aplicativo não irão encontrar erros ou ficarão perdidas.

Vale lembrar ainda que, pelo sim ou pelo não, sempre te daremos um feedback. Se por algum motivo você não for aprovada(o), te enviaremos uma lista com os pontos onde você poderia ter ido melhor e as respectivas recomendações de estudo. Trabalhe esses pontos e, quando julgar que conseguiu evoluir, se candidate novamente no nosso processo seletivo. Por curiosidade, algumas pessoas do nosso time participaram do processo seletivo mais de uma vez. Se você for aprovada(o), prometemos muitos desafios e aprendizado.

Para saber mais como serão seus primeiros meses de trabalho, indico dois posts para você: One year working at plataformatec (escrito também por mim) e What I have learned in my first three months at plataformatec (escrito por Igor Florian).

Espero que tenha gostado dessas dicas. Se você gostou e acha que elas se relacionam com a maneira que você gosta de trabalhar, inscreva-se no nosso processo seletivo.

Para outras dicas de como mandar bem no desenvolvimento de software, recomendo também dar uma olhada nas palestras Learn From My Mistakes da Flavia Fortes e 10 Coisas Que Eu Gostaria de Ter aprendido Mais Cedo do Lucas Mazza.

Espero ver seu código em breve

The post 6 dicas para mandar bem no código do processo seletivo da Plataformatec first appeared on Plataformatec Blog.