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:
http://jamescowie.me//blog/2016/12/all-hail-xdebug-and-lets-let-var-dump-die/

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.

 

Avoiding the Do-Nothing Retrospective






This is a lesson i've learned many times running my own company: "ending a meeting without a decision is disruptive".

You are investing time discussing, analyzing, gathering data, process information and  multiply that for the people involved. And if the meeting give no action then it's a waste.

A 2h meeting for 5 persons could be 10 wasted hours.

You can apply the same to Retrospectives, repeat this mantra with me:
Avoid the Do-Nothing Retrospective

This is not only true but extremely true.

Keep in mind why do we retrospect: Not because the Scrum guide says that but because we want to improve. And we believe we can do it through inspection and adaption.

So take at least an action as result of the meeting, if you think everything is perfect, but i assume is not, use a simple:

"Keep the things running smoothly and great like the past sprint".
And trust me even trying to replicate a great sprint is not so easy.
If you know and understand why the past sprint was so great you can create your team list of good habits to perform well again.

In real cases we found many things not running well, which most likely a common path, in those situations the suggestion is to avoid too much changes, and work on one or two improvement(s) at time.

Sometimes when is not possible to find a solution in the retrospective meeting I encourage the team to schedule a dedicated meeting to discuss the topic and find a solution, people has time to prepare and maybe experiment some idea and be ready for a very focused problem solving meeting. Those meetings could be done by just few team members or maybe some team members and some external persons.

Not only avoiding the disruptive do-nothing retro is vital but also avoid the "Blaming external causes Retrospective".

Last but not least keep in mind those wise words from the book "Agile Retrospective - Making Good Teams Great" by Esther Derby, Diana Larsen:
Change happens in the course of normal work. Teams who believe their retrospectives are a waste of time often keep their improvement plans completely separate from their daily work plans. When the plans are separate, no one finds time to do the “extra” work.

 





 

Scrum Master Service to the Product Owner

From the Scrum guide:
The Scrum Master serves the Product Owner in several ways, including:

  • Finding techniques for effective Product Backlog management;

  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;

  • Understanding product planning in an empirical environment;

  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;

  • Understanding and practicing agility; and,

  • Facilitating Scrum events as requested or needed.


How much are you coaching the PO and the Dev Team? Are you just a secretary or a proactive SM? Are you stressing the PO to create right user stories or just accept everything he ask?

Scrum Master Service to the Development Team

From the Scrum guide:

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;

  • Helping the Development Team to create high-value products;

  • Removing impediments to the Development Team’s progress;

  • Facilitating Scrum events as requested or needed; and,

  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.


How much of those point are you really working out on your daily basis?
In a scale from 1 to 5 try to vote yourself in all of those points.