I can estimate how long it will take me to drive to Des Moines, and be "close enough." There are lights, stops, traffic, weather to consider, but mostly it's me choosing route and rate. Route has speed limits, traffic features, raw distance. Those are not up to me, really. I have limits, but the limits make the trip predictable.

Self-care thought for the day: I can't be there for you if I'm not there. I can't be a voice of reason if I'm unreasonable.
Can't show love, curiosity, openness, kindness if I don't have it in me.

Often businesses run fast, in the unsafe fast quadrant of the graph. They end up so hampered by low quality that they are dragged into unsafe slow. We refer to the unsafe-slow quadrant as "hell" - no matter how fast you try to go, things go wrong and you end up fixing and reacting to crises. And of course you get there through good intentions.

"If one of us is remote, we all work as if remote" is questionable. While it creates empathy/sympathy and urge to fix remoting problems, if one of us broke her wrist we wouldn't all type with non-dominant hand for 6 weeks. Not reducing the value of empathy, but when I'm remote I accept that it is not as good a group experience and don't want everyone to give up their advantages. My choice to work as a remote shouldn't hobble everyone else.

In the early 90s, a coworker named Dan conscientiously told us that he would be happy to help us with "our" work, but only after he finished "his work" because he won't put his reputation at risk for us. At the time, I was working with almost everyone else on the team on "their" work while trying to finish "my" work. It was before we understood teaming, when everyone thought in "individual contributor" terms, but I had already been on two excellent real teams.

there is this idea floating about inverting business, to wit:

* There are people in your org who materially participate in delivery of goods/services/etc
* Then there are supportive functions provided as a service to material participants
* Then there is dead wood It's interesting. It suggests that the people building, designing, and selling your cars are "the real business," managers and purchasing and HR and finance are supporting the primary functions, and anyone not supporting design/build/deliver are basically waste.

Simplification has a rule:
1) Make the thing unnecessary
2) Then get rid of it.

Don't throw away the crutch while you're leaning on it. This has relevance to every #No<thing> hashtag. If you reduce or eliminate a need, you can reduce or eliminate a practice or role.
Maintaining unneeded practices and roles is waste.

A: How long is a story point in real time?
B: How many did you do in your last sprint?
A: 23
B: Then, for you, it's a 23rd of a sprint
A: But the time before that it was 19
B: Then for you at the time it was 1/19th of a sprint.
A: But how long is it really?
B: We answered that. A: but my next sprint needs to be 30 points.
B: What has changed to make a point be 1/30th of a sprint?
A: We need it to be.
B: Then improve something significantly.
A: Can we just try harder?
B: There is no evidence that works.

For decades now, people are taught a definition of "success": a successful team delivers the full scope on time and under budget. It has been the mantra of project managers, and has been taught in books, in magazines, in college classes, and by word-of-mouth for GENERATIONS of managers and workers.

All anger presents as righteous indignation. Have you ever been angry and not convinced you were not right to be so? It is only in retrospect that one realizes that one was in error, with embarrassment and shame.

When you hear "those people are always complaining" then you're looking at a systemic problem. It's probably not a personality type; it's probably that the system in play disadvantages them constantly. It's easier to do victim-blaming, but maybe it's time to investigate. The Fundamental Attribution Error is too easy to fall into, especially when it allows you to write off a whole group of people you don't know how to please.

You know that the sprint goal is not a number: not story points, not a count of features, not a velocity? It's supposed to be an outcome. @mediafinger It's a symptom of a (so-called) feature mill to mistake the load for the goal.
If ever the sprint goal is "complete all these stories" you know that you've crossed a line, and it's time to retrospect.

What is your role in the code base you find yourself in today?
Owner?
Renter?
Guest?
Visitor?
Vandal? I ask seriously, because I'm learning that the answers matter.
A lot.

If cynefin did nothing else, it has certainly made us aware that not everything can be solved with a clear, preplanned, recipe-like formula. We should only develop those when they're appropriate. Another useful feature is that it makes us aware of boundaries; going from complicated to complex (for instance), it is now "common sense" to rethink our way of working.

Once upon a time people argued that TDD is impossible.
You can't write a test first, obviously, because you can't test something that doesn't exist. It's obviously ludicrous.
But you change how you think about "a test" and it works just fine. Likewise, two people working at one machine? Ludicrous! That's twice the cost! Except that when you realize that programming isn't typing, it makes easy sense, and it also works just fine.