There's a lot here and if you're not sure where to start, here are some popular starting points. From these, you'll find crosslinks to even more topics. Enjoy! For other kinds of content, see my other blogs at Unconscious Agile and Agile Technical Excellence.

Supporting the new hires

I’m seeing more posts saying that new hires need to be in the office because they ramp up faster, than if they’re remote. There’s a fundamental presupposition in these statements that once we’ve hired these people, we’re immediately going to throw them to the wolves and have them work all by themselves.

The facilitators role

If you’re facilitating the daily coordination meeting (standup, daily scrum, whatever you want to call it), and you’re doing all the talking, then you’re doing it wrong.

Risk Management

Yesterday I went on a guided hike to teach people how to safely hike through bear country. Specifically grizzy bear country. Unfortunately, we didn’t see any bears, but we did learn an amazing amount about them, and saw some spectacular glaciers and alpine terrain.

Gaming metrics

When I suggest that people will game whatever metrics we put in place, I’m often met with shocked indignation. We would never game the numbers! And yet we do.

OKR’s for Quality

The topic of OKR’s for quality have come up in multiple different contexts, across multiple clients, recently so perhaps it’s worth exploring.

Prioritization

There two different times that we need to prioritize work and we should be using completely different approaches to that prioritization, for each stage.

Wait states

The metrics covered in our Flow Metrics Basics class show how to measure different aspects of flow, but those metrics don’t in themselves, show how to improve the flow. We’ll look at one way to improve now.

Playing the long game

If I was planning to disband my team this week and I only cared about what they could deliver in a couple of days then I’d be focused on making sure that everyone was doing that piece of work that they were most skilled at.

Building the right thing

When I’m working with a development team, I’ll often start by having them walk me through what business need they’re solving for. I’m less interested in the code or the architecture until I’ve first understood what problem we’re trying to solve.