Serveo is a ngrok like free alternative to expose your localhost

Serveo is an alternative to ngrok.

PRO: does not need to download a software or to register to a service

CONS: no fancy dashboard


ssh -R 80:

it generates a subdomain like  that redirect the traffic on your local machine on local port 32775:

I'm using it on DDEV and works also with the XCode Simulator.

check it out at

Git delete merged branches


git branch --merged | egrep -v "(master|development)" | xargs -n 1 git branch -d

Dry run

git branch --merged | egrep -v "(master|development)" | xargs -n 1 echo


git branch -r --merged | egrep -v "(master|development)"| grep origin | sed 's/origin\///' | xargs -n 1 git push --delete origin

Dry run

git branch -r --merged | egrep -v "(master|development)"| grep origin | sed 's/origin\///' | xargs -n 1 echo

Once you delete the branch from the remote, you can prune to get rid of remote tracking branches with:

git remote prune origin

CSS hover apply to parent elements

Imagine you want apply the hover effect to the whole parent element but just when mouse over a child element, pure CSS no JS

Here the trick:

Mac Xdebug PHPStorm DDEV Docker when the normal configuration fails

Setting up Xdebug on PHPStorm seems pretty straightforward, easy and quick, just following the brainless Zero-Configuration Debugging right?

Well not in my case. Or better, it was working fine but suddenly it stopped working. And after resetting everything and digging hours on stackoverflow and blogs, at the end I came to this solution, basicly forcing docker and my Mac tunnelling

Here my solution

If you want read the full article when I come to the working solution, click here:

TYPO3 on Mac easy with DDEV and Docker

Do you like have a TYPO3 dev environment or just testing the new version 9 on MacOS?
Follow those simple steps with ddev:

What's wrong with the daily? Why teams want skip it?

I've heard something alarming from a couple of teams i had the honor to serve in past and current days.

They want skip daily the day after planning!

For me it's an absolute no-go, but why that's happening in different teams is the question? Is it just a coincidence?

So I asked the same question to other Scrum Masters and in a well known group of scrum experts and I got different interpretations.

Some scrum masters told me "why not skip it if the team like it?" or "if is the day after the planning they don't have much to sync".
And asking team members I got answers like that: "since we had the planning yesterday we don't have nothing to report" and defend the position with "we agreed that with the former SM, why you bother us with that question again?".

I got the idea those guys think at the daily just like a report.

What I learned as SM and former developer is exactly what's written in the guide, the daily serves to plan the today's work:

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

For me that's simple, the daily is a must and should be done in each day during the sprint.
Of course not when one of the other main events like review or planning occurs in the morning (or at the daily time in general).

But again why this doesn't happen right now?

I think, it's because the "3 question approach" is interpreted like a sort of report, and often in direction of the PO instead of the team.

How can we have a more useful daily? I think a solution is to find another "structured" way to help the team mates. In fact the current is a very simple template to follow. Can we build another simple template but more collaborative one?

2017 Scrum guide revision

What’s happened on November the 7th?

A new revision of the scrum guide was released with a video webinar explaining the changes. 

  • A wider scrum definition

  • Refined the scrum master role definition

  • A more modern daily definition

  • A strong push to the improvement phase, adding a improvement story to the sprint backlog from the retrospective feedback 

  • Time boxed events revised 

To me the very big differences that touch my work are related to put a improvement item in the sprint backlog and the daily. 

What’s yours?

You can read more:

Avoid the "blame external problems" retrospective

In every organization there are out-of-our-control problems. We don't live in isolation, even if ideally we are in a room not distracted during our sprint, there are external influences.

And that's normal.

What's important to recognize is that it's impossible to live in an ideal world. We don't and we'll never do.

Someone has to sell our services, deal with clients, sign contracts, give support. Someone is sick, in late, or have a disruptive behaviour.
Our team live in contact with other actors of the big development game: designers, sysops, managers, and the shareholders and stakeholders, nonetheless the PO sometimes could give us headaches.

Ideally all the actors should convey with the team about all details, the team should be formed around the project. Ideally we have meetings in time and timeboxed and the client is always joining our Reviews.

But what happens when it doesn't work as expected?

Teams blame externals. And feels bad about the inability to change the situation.
Often because those causes could last for long time, if not forever (or for the project/team/company life).

For example if the management impose the team a project, without giving opportunities to discuss and deal on scope, budget and time, the team will be most likely in trouble sooner or later.

If the project depends on external producers not included in the team, for example graphic designers or UI/UX experts, the team has a possible issue.

If the Client willings to be part of the game is very low, because "he just wants what he has signed for", the team is in serious probable troubles.

The agile culture in many companies in not complete at all levels and often teams depends on others.

And it's simple not possible to do in different way (or change quickly). And teams start blaming outside-problems.
My suggestion is that even in those situation, which i admit are quite complex to solve, the team should focus on what can do, more than what can't.

Simple because blaming outside doesn't solve issues. Working on issues solve issues.

During retrospectives try to move the focus on what could be done, not on external problems. But as SM work harder on those issues, they can destroy a good team.


A wise man told me:
Scrum is the art of doing what's possible and ignore what's not possible.

or in other words:
Start by doing what's necessary. Then do what's possible. And suddenly you are doing the impossible.

I would advise some simple suggestions:

  1. Learn to say NO

  2. Don't blame but do your best, have a positive attitude, be an example, other persons will follow

  3. Be smart and have a flexible mind

  4. Be patient, you cannot complete a big puzzle in one day, it needs time and patience but constance enlightens the path to put all pieces together

  5. Learn to mediate and strengthen collaboration, if problems comes from outside collaborate with people around it's a way

  6. Coach and teach Agile values, but please just don't say "you're not following agile values" that's just another blaming approach ;)



Here some wise words from "Agile Retrospective - Making Good Teams Great" by Esther Derby, Diana Larsen:

Teams who identify external groups as the source of their ills and want those people to change end up frustrated. Waiting for other people to change is an exercise in futility. The most powerful place to start change is within the team. Even when your team doesn’t have direct control, your team can take action to influence or change their own response.