Agile is still Dead :: Portugal – Brasil, Cafe com Rey

It was last Saturday that I got an invitation to be the speaker on a very friendly and informal meetup named, Cafe com Rey. It’s a small community of Brazilian Agilists scattered between Rio de Janeiro and Joao Pessoa.

My biggest take away from this moment is: if you are open and willing to help amazing things happen.

And why is that? It was on the previous Saturday before the meetup that I got a LinkedIn message from Rey asking me if Agile was really dead. When I got the message I had three options:

  • Ignore
  • Reply without being open to continue the interaction
  • Reply with openness to continue the interaction

If you know me by now, you know that I went for the third option, and so that’s how I got to meet Rey (an amazing person) and the rest of the group, and I also had the change to refresh my Agile is Dead presentation.

After 3 years of delivering my first “Agile is Dead” presentation, I updated the title of the talk to “Agile is still Dead” and I revisited some slides.

And so this is it. Even today I’m still amazed how replying back to a LinkedIn message, open to interact, with genuine interest, led me to make another talk, meet new people and have a good time on a Saturday. A lesson for life. ūüôā

Here is the talk Agile is still Dead in case you are interested in peeking the slides.

See you soon!

Hara-Kiri from Engineering (Best?) Practices :: 2020

Last Wednesday, on the 29th of April, I gave my first “virtual”/”remote” talk of my life. It is definitely very different from speaking in front of a “live audience” but taking in consideration the current situation (i.e. covid-19) it was pretty much following the saying “the art of the possible”. Congrats to for organising a tech week and proving that it is possible to share knowledge and to foster a sense of community even in a less positive moment of the human kind.

The conference had fabulous speakers as you can see by yourself in the event’s agenda.

My talk was called “Hara-Kiri from Engineering (Best?) Practices and you can see the intro/abstract here. The subject is around engineering practices that although are considered best practices, they also have pitfalls that you should watch-out for.

Here are the key take-aways from the talk:

  • Tech Debt shouldn‚Äôt pile up nor be fully paid. It should be managed;
  • Bus Factor should never be 1 but shouldn‚Äôt be huge too. It should be in the sweet spot;
  • Squads are a great concept but are a challenge in broad/deep architectures. The Squads‚Äô depth is key for success;
  • It‚Äôs easy to get lost in resiliency, availability, and scalability work. Your systems should be dimensioned for your near future reality;
  • Code coverage is a great metric to keep track of. You can have 100% code coverage and still have bugs in your code;
  • Being Agile is not about (blindly) following a process. Agility is the ability to quickly gather and act upon feedback;
  • It‚Äôs easy to fall into the trap of adopting complex, oversized approaches. You should favor simple and elegant solutions with your near future in mind;
  • It‚Äôs easy to find ‚Äúflaws‚ÄĚ in others‚Äô solutions (you find what you look for). Using existing solutions (e.g. open source, SaaS) accelerates time to market;
  • Loosely coupled services are great to scale but not brilliant to start with. Make sure you know the effort and cost of using them right off the bat;
  • Adopting a new coding language shouldn‚Äôt be a light-hearted decision. Usually architecture solves problems not coding languages;
  • Remember that the code you write today is legacy tomorrow. ‚ÄúLegacy‚ÄĚ is usually what pays our salaries;
  • Pull/Merge Requests are great guardrails but it adds a step on your flow. It enables feedback and knowledge sharing if taken seriously;
  • It is normal to be risk averse and avoid deploying code on certain occasions. You should strive to deploy at any moment, ideally multiple times a day.

If you are interesting in seeing the slides you can see them here.

And last but not least here is the video if you would like to watch the talk:

See you soon!


The last time I wrote here was during the Summer of 2019. August to be more precise.

I’m wondering why I “stopped” writing… I guess I didn’t have the will to do it. Writing is a strange phenomena, at least for me, or you have a crazy will to write with a good cadence… or you don’t have the will to write at all.

Now here we are, with the first quarter of 2020 gone… and with so many changes since the last post. To name a few:

  • The World is in the middle of a pandemic that will change the World as we know it. In a couple of quarter a new normal will settle in;
  • I’ve changed jobs. After near 4 years working at Talkdesk I decided to take a new challenge at Salsify;
  • I’ve moved to Lisbon. Yes, after living and working in Porto, Lisbon, London and then back again to Porto… I moved to Lisbon to work at Salsify (it’s where the EMEA offices are).

So as you can see the only constant in life is change.

I also decided to take a break from Public speaking… but I “failed” miserably at that attempt since I accepted the first invitation that came up (thank you for the kind invitation).

I’ll write a post about my presentation (it was yesterday) since I have the slides and the video to share with you all.

In the meantime, stay safe, stay home, and look after you and your loved ones.

See you soon! ūüôā

Loose thoughts on Remote Work

(I’m going to write this post in English since I believe this is a concern to everyone in the World and not just for Portuguese speakers)

Some years ago I was one of the non-believers of Remote Work (RW).

And the reason for that was because RW for many years (and even today) has been misused, let’s see:
– it was for cost reduction (e.g. salaries, office space);
– to deal with crappy work (that co-located folks didn’t want to do);
– to work in an asynchronous way;
– it used several timezones (some of them with +8 hours difference);
– to have access to a very specific skillset;
– to have the minority of the team (usually one person) working in satellite mode (i.e. all the team is co-located with just one or two people working remotely);
– for the developers to be productive / be in the zone without noise/interruptions (in fact the only behaviour that was being valued here was individualism and not productivity).

No wonder a lot of people (like me) didn’t believe in remote working.

And we also need to take Agile in consideration and the legion of Agilists “preaching” for the co-location of teams.

But… And there is always one but… RW can actually work and be an amazing thing! You just can’t mess things up and follow a KISS approach.

And what showed that to me was actually two examples, that although didn’t work flawlessly… they did work:
– I once worked next to a team that had a remote person (with one hour difference) and in order for the team to work well he was projecting himself all the time and had his microphone “open” all the time and he was accessible to all the team. He was on being projected on a computer and if anyone from the co-located team needed the person they would just walk to the computer and spoke to the remote person. The team also worked all the time in pair programming which I believe helped a lot;
– I also worked for about a year with a brilliant person that remotely ran a team of +100 engineers. This particular person helped the engineering team grow from 10 engineers to 100 remotely. Yes, you read it right… Remotely!

Now that (hopefully) I convinced you that RW can work… I’m going to tell you what I believe RW should be like in order to work flawlessly:
– everyone is remote. There is no middle ground here… or everyone is co-located… or everyone is remote. Plain simple;
– everyone should be in the same time-zone… with “tolerance” for one hour (plus or minus) difference max;
– all work should be synchronous (just like co-located teams);
– you need the right tools (e.g. Sococo) where you are all projecting your video and talking to each other all the time (just like in an online First-person shooter – FPS – videogame);

And the advantages of that are:
– you are all remote with the (majority) of the benefits of co-location;
– you can work from wherever you like (e.g. home, coffee shop, country house)
– it can give you access to some people (and some skillsets) that due to their location you couldn’t count on them (e.g. Alaska, Grenada, Tuvalu, Freixo de Espada √† Cinta);
– you’ll be working from a more comfortable place than the typical office
– you won’t need to worry about commute time;
– you can (be closer and) spend more time with your family, friends, pets and other things that have meaning in your life.

For me, it is a no brainer that RW works and it will be an increasing trend of this century.

So hopefully we’ll stop “suffering” from so many approaches from recruiters (usually on LinkedIn) asking for professionals to relocate to locations thousands of km/miles away from where you are currently based… and we’ll see more remote jobs appearing and with that changing (and dramatically improving) people’s lives.

Don’t get me wrong… Co-location is (usually) better than RW… But not only RW can work… As it can unlock some very interesting possibilities that co-location can’t. So both are great… you just need to decide which one is better for you.

Unicorn On-call :: “Portugal tour” :)

Apesar de estarmos no Ver√£o, estamos a viver um Agosto a fazer lembrar o Inverno.

Com o Ver√£o faz-se uma pausa no calend√°rio das confer√™ncias (salvo exce√ß√Ķes).

No m√™s de Junho tive a honra de fazer a minha apresenta√ß√£o “Unicorn On-call” em tr√™s eventos nacionais:

  • DevOpsDays Portugal;
  • Tech in Porto;
  • Landing Festival Lisbon.

A apresenta√ß√£o tem como objetivo celebrar a coragem, determina√ß√£o e dedica√ß√£o dos engenheiros que abdicam do seu tempo livre para olhar pelos sistemas das empresas e por consequencia pelos seus clientes. Esta atividade √© normalmente designada por “on-call” ou “preven√ß√£o”.

Dos vários temas abordados na apresentação, gosto de destacar três:

  • Sofware Engineer a fazer on-call, na medida em que n√£o acredito em equipas dedicadas a fazer on-call e porque acredito que as pessoas que desenvolvem sistemas devem tamb√©m mant√™-los;
  • O on-call deve ser em regime de voluntariado, ou seja, as pessoas n√£o devem participar por serem obrigadas mas sim porque acreditam que o devem fazer;
  • Quando utilizamos “gamifica√ß√£o” conseguimos excelentes resultados (em v√°rios n√≠veis).

Deixo ficar os meus slides, aqui, aqui e aqui. Todos t√™m (ligeiras) diferen√ßas. ūüôā

Deixo ficar aqui também o video de apresentação do programa Vanguard (programa de on-call com gamificação):

E aqui fica a minha apresentação no Tech in Porto:

Até para a semana.

Product Panel – “How to scale a product team?” :: Landing Festival Berlin 2019

Por vezes escrever um post cedo de mais d√° nisto… ūüôā

Acabei por ter mais uma participa√ß√£o (que n√£o estava √† espera) na Landing Festival: Fui convidado para ser o moderador de um painel com o t√≠tulo “How to scale a product team?”.

Os painelistas foram:

Tivemos 60 minutos √† conversa sobre como “escalar” uma equipa de Produto. Foi uma sess√£o muito interessante com a prespectiva de 3 pessoas com background e experiencias muito diferentes.

Foi uma experi√™ncia inesperada mas a repetir! Obrigado Pedro Saraiva (e pela oportunidade! ūüôā

Até para a semana.

When Product meets Engineering :: Landing Festival Berlin 2019

Esta semana est√° a ser uma semana de “estreias”:

Ora bem… primeiro sobre a confer√™ncia: √© simplesmente impressionante como √© que a Landing Jobs consegue organizar uma confer√™ncia em Berlim com imensos profissionais, curiosos e estudantes da √°rea. A confer√™ncia tem speakers espetaculares como a Sandi Metz e o Gojko Adzic e ainda um espa√ßo para as empresas marcarem presen√ßa com as suas booths a tentarem atrair talento.

Em rela√ß√£o √† minha talk tive uma rece√ß√£o (surpreendentemente) muito positiva! Basicamente questiono a estrutura cl√°ssica “Produto vs Engenharia” ou “Neg√≥cio vs IT” (depende dos termos usados em cada organiza√ß√£o) e proponho uma estrutura chamada ARM: “Acquisition, Retention and Monetization”. A ideia por detr√°s desta estrutura √© simples… Produto e Engenharia devem co-existir em √°reas verticiais estrat√©gicas da empresa (Aquisi√ß√£o, Reten√ß√£o e Monetiza√ß√£o de clientes) e n√£o serem √°reas por si. Podia escrever mais sobre o tema em si… mas √© mais f√°cil assistirem √† talk. ūüôā

Me on stage

Quanto a Berlim… √© uma cidade bem diferente das que eu j√° visitei: podemos estar numa zona chique / posh com pre√ßos car√≠ssimos… e passamos para a rua do lado e parece que estamos de volta a 1980 com pre√ßos iguais aos do Porto (ou Lisboa). Aqui ficam alguns fun facts de Berlim:

  • Toda a gente bebe cerveja (de meio litro);
  • A cidade √© bastante suja… faz-me lembrar o Porto h√° muitos anos atr√°s;
  • Tem ruas muito bem cuidadas e estimadas… e outras completamente vandalizadas;
  • Um caf√© custa tanto como uma cerveja;
  • √Č f√°cil para um visitante (como eu) beber mais cerveja do que √°gua (tipicamente com g√°s);
  • Vi mais pessoas de bicicleta nestes dias que num ano inteiro no Porto ou em Lisboa;
  • N√£o vi tr√Ęnsito nem o metro cheio (mesmo em horas de ponta);
  • Para se viver em Berlim n√£o √© necess√°rio falar Alem√£o (mas d√° bastante jeito porque h√° muita informa√ß√£o espalhada pela cidade apenas em Alem√£o);
  • Tem empresas espetaculares como a Zalando e a N26 (para al√©m de imensas outras startups).

All in all a experi√™ncia tem sido espetacular e agrade√ßo imenso √† a oportunidade de viver esta experi√™ncia. ūüôā

Até para a semana.

Psychological Contract, Internal Branding and Employee Turnover in an IT Company

Foi publicado ontem um artigo que teve como origem a minha tese de mestrado.

A Mediterranean Center of Social and Educational Research, através do Academic Journal of Interdisciplinary Studies, publicou o meu artigo com o título Psychological Contract, Internal Branding and Employee Turnover in an IT Company.

Deixo um especial Muito Obrigado ao Abílio Oliveira e ao Sérgio Moro por toda a ajuda, trabalho, empenho, convicção e perseverança. Sem eles este artigo não seria publicado.

Para quem tiver curiosidade pode aceder ao meu artigo aqui ou aqui.

Até para a semana.

Comunica√ß√£o em equipas √Āgeis: Desafios e Conquistas

Aconteceu no passado sábado o evento de referência da IPMA Young Crew Portugal, o PM4ALL, em Lisboa.

Foi um evento muito interessante onde tiver oportunidade de conhecer a Marisa “the Lucky PM” Silva, a Andreia Henriques e onde revi v√°rios amigos. Parecia que estava em casa. ūüôā

O dia foi muito bem passado com sess√Ķes (pain√©is e apresenta√ß√Ķes) excelentes. Gostei imenso da apresenta√ß√£o sobre Rapport da Ana Ma√ßas e da Lara Cunha.

Tive tamb√©m oportunidade de abra√ßar a Sara Batalha o que foi, no m√≠nimo, inesperado! ūüôā

A apresenta√ß√£o que foi simplesmente overwhelming pelo conte√ļdo e pela forma super original foi a do Eduardo Espinheira que fez-me ganhar o dia. Ligar Gest√£o de Projeto com o “Principe” de “o tio” Nicolau Maquiavel e n√£o dizer uma √ļnica palavra durante uma apresenta√ß√£o foi realmente uma li√ß√£o de creatividade e de como estar em palco.

A minha apresenta√ß√£o foi sobre comunica√ß√£o (o tema do PM4ALL deste ano) e equipas √°geis e tinha como t√≠tulo “Comunica√ß√£o em equipas √Āgeis: Desafios e Conquistas“. Abordei o tema mostrando que a pobre / falta de comunica√ß√£o √© um dos maiores motivos de insucesso dos projectos, demonstrei como √© dif√≠cil comunicar (por causa da diversidade de canais dispon√≠veis, das emo√ß√Ķes, da urg√™ncia, da efetividade e do efeito “telefone estragado”) e como o facto de termos equipas grandes torna a comunica√ß√£o muito dif√≠cil dentro da equipa. Falei do livro “The Mythical Man-Month” de Fred Brooks e falei sobre equipas co-localizadas e remotas.

Tive imensa pena de ter de “fugir” √†s 17h00 de volta para o Porto mas a um S√°bado n√£o tinha margem para ficar at√© ao fim do evento.

Foi um evento espetacular, organizado exclusivamente por pessoas em regime de voluntariado, e que n√£o me deixa d√ļvidas que para o ano ainda ser√° melhor. Recomendo!

Aqui ficam duas fotos da praxe:

At√© para a semana. ūüôā

Agile is Dead :: Wrap-up

Ao fim de 4 apresenta√ß√Ķes do Agile is Dead (no Pixels Camp, no Aginext, no Agile Connect e no Viana Tech Meetups)… acho que vou dar um “descan√ßo” √† minha apresenta√ß√£o que maior sucesso e aceita√ß√£o teve (se bem que ainda devo esta apresenta√ß√£o √† comunidade da Netponto… por isso vamos ver se n√£o haver√° uma √ļltima apresenta√ß√£o).

A verdade é que este tema está cada vez mais atual que nunca.

Sen√£o vejamos:

  • Vemos novas empresas a quererem come√ßar o seu caminho √°gil;
  • Vemos empresas que j√° faziam h√° bastante tempo a sua travessia¬† a voltarem a tr√°s e a questionarem/repensarem o √°gil;
  • Vemos consultores a auto proclamarem-se “transformational, organisational, enterprise, technical, lean, agile coaches” sem terem experi√™ncia relevante na √°rea;
  • Continuamos com os mesmos trainers a amealharem milhares de euros por cada “curso” de 2 dias;
  • Vemos N vertentes de √°gil a surgirem: quer sejam pelo desafio de escalar (exemplos: SAFe, LeSS) quer seja pelo desafio de fazer as coisas de forma diferente (exemplos: Agnostic Agile, Modern Agile);
  • Vemos implementa√ß√Ķes de Scrum, no m√≠nimo, question√°veis em v√°rias empresas;
  • N√£o vemos melhorias √≥bvias, evolu√ß√£o na comunidade (comunidade esta que apregoa a melhoria cont√≠nua);
  • Vemos poucas comunidades ativas de aficionados e praticantes √°geis (uma boa exce√ß√£o a este cen√°rio √© a Agile Connect);
  • Vemos empresas a questionar o √°gil quer seja porque t√™m/tiveram as pessoas erradas a liderar/dinamizar o movimento quer seja porque n√£o tem paci√™ncia para esperar pelos resultados;
  • Vemos empresas a n√£o obterem os resultados de delivery desejados e a “culpabilizarem” o √°gil.

E o que devemos fazer perante isto?

As (poucas) respostas que tenho para dar s√£o:

  • Voltar para/continuar a fazer waterfall n√£o √© solu√ß√£o;
  • As empresas t√™m que ser muito mais exigentes com quem contratam para os pap√©is de scrum master/agile coach/consultor;
  • Definam crit√©rios de sucesso claros entorno da ado√ß√£o do √°gil;
  • Me√ßam os resultados obtidos (quantitativos e qualitativos);
  • Evitem febres, modas e caminhos “r√°pidos” ou “f√°ceis”.

E pronto… ao fim de 4 meses sem escrever no meu blog tinha de voltar com um post deste estilo. O meu objetivo n√£o √©, nem nunca foi, denegrir o √°gil… mas sim aumentar o sentido de urg√™ncia para que fa√ßamos alguma¬†coisa em rela√ß√£o ao seu status quo.

Até para a semana.