Don't just blindly apply dailies. Make sure they really solve a problem in your team.

You have to be willing to experiment and adjust in order to truly be agile. Otherwise you indeed just do dailies and call yourself agile.

Nice check list, there's more to project life than churning out tickets.

Hear, hear! If you go through rituals without understanding the values and principles... It's not Agile anymore so stop pretending. Another certification isn't going to save you at this point.

If your team is solely in "pushing tickets out" mode, there's indeed a problem. Teams needs more agency and care for the output to actually strive long term.

A bit of a forgotten approach I think. A good way to quickly gauge projects, show the amount of work and spot the dependencies.

Definitely this, as projects scale, keeping an eye on dependencies between teams is key to efficient allocation. This will happen by trying to eliminate said dependencies, reallocating between teams.

Interesting findings about procrastination. Some effects were expected, others less so. The actions to avoid it in teams should be well known now.

Definitely this, too often I see projects treating the technical debt as one-off large tasks. Really it's something you should deal with bite sized and over time.

Don't throw estimates out of the window. Keep in mind that the more precise they are the more expensive they become.

If you're asked a broad project estimate, building a very fine grained user story list is likely not the best approach.

If you spend your time in dull meetings and then run like a headless chicken... it's definitely a sign you should cut down on the meetings and keep only the ones focusing on solving actual problems.

Good approach to detect problems early and manage the risks they'll bear.

Interesting thinking around a portfolio of activities. You can prioritise differently within it to manage quality vs speed of delivery over time.

Or why it can be dangerous to label medium the high likelihood low impact risks and the low likelihood high impact ones. One category is to be completely avoided while the other brings learning opportunities.

Or why you can't consider risks in isolation. It's too often forgotten.

Interesting extra dimension to think about risks. I don't think I ever encountered it in the wild but that can make sense to use it.

Struggling with making your first technical roadmap? Driving it from measurable problems is a good first step.

I don't exactly use this approach to factor in the uncertainty... but I guess there's something to be made out of this proposal. I'll keep it in mind for my next project.

Excellent article introducing how to analyse risks.