Async code reviews aren't the problem.

Async blocking code reviews are the problem.

Async isn't the issue for flow. Blocking is. Code is reviewed asynchronously all the time, every time we make a change.

What process do you think yields higher quality?
A process where code is improved only through PR reviews?
Or a process where code is improved every time somebody finds something to improve?

Tips (not only) for the (remote) DSM

*Prepare!*

Everyone
1. Make sure that all information is correct and reflects the latest state and knowledge
2. Be on time
3. Camera on

Leads, SMs, Coaches
1. Walk the board prior
2. Take notes of all your findings
3. Use your notes *Be clean!*
1. Title correct?
2. Description complete?
3. Acceptance criteria present?
4. Priority? Ranked accordingly?
5. Flagged?
6. Other mandatory information present and current?
7. Assignment correct?
8. Type correct?
9. Estimate (maybe, or just count)?

"We're Agile."
"So you don't use Pull Requests?"
"Oh, but we do."
"Sorry, you're not Agile." "We're Agile."
"So you have >10% Slack time?"
"No, we utilize our team 100%."
"Sorry, you're not Agile."

In unit testing, what's a unit? Is it a method? Is it a class? Is it a module? No. Let's clarify this once and for all.

In unit testing, a unit isn't an element of structure. In unit testing, a unit is an individually observable element of BEHAVIOR.

#TDD #BDD #ATDD #UnitTesting BTW I use @mfeathers explanation that "unit tests are tests that run fast" as a possible valid (foundation/element of a) definition of the term unit test.

Agile is much more about reducing lead time, defects, and all kinds of wastes by empiricism (feedback; transparency, inspection, adaptation) on all various scales of time (from seconds to months) than any particular method or framework. Your practices, methods, and frameworks should be aligned with this: Check where you are, decide where you want to be, go a small step in that direction, look at how that worked, and repeat. Establish that cycle on various time scales.

It seems it's that time again to clear up some misconceptions about DevOps. A thread. DevOps means Development Operations. If your team isn't doing both, development and operations of the same product/project, it's not DevOps.

Today is rant day. Let me see what I've got.

Scrum is bullshit. Skip it. Directly move to XP. Warning: occasional strong language ahead.

Scrum is all about empiricism. Empiricism is good. Empiricism is usually not the problem. In fact, Scrum can even increase the problem.

Are you ready for a little thread on a few aspects of software (re-)design, sparkled with inspirational quotes around the topic?

Let's go! "Life is really simple, but we insist on making it complicated."
― Confucius

The fundamental vim ideas:
• Commands come in sequences. Having a command mode allows commands with fewer keystrokes and fewer modifier keys to make you more efficient. Also, move away less from the touch typing homerow.
• Commands are mnemonic. For example, z for folding...

https://twitter.com/tottinge/status/1190001054831788036

...z looks like a sheet of paper when folded.
Why hjkl? Touch typing homerow. Of that, h is left, l is right. The shape j goes down, k goes up. I don't remember specifically what hjkl do, I just remember that the whole editor is mnemonic. That way I remember more with less.