What does software development look like from the outside?

I request N things. A few of them come out months later.
Hence: these programmers need to work faster.

1/ however, each of the N things really only took about 4 days to complete on average. Working 2x as fast (a dubious prospect) would carve off only 2 days from delivery time.

2/

Test first - red.
Oh, I don't like the way that message reads.
Ah, better. Code - not green?
Quick, most obvious solution.
Still not green.
Oh, why didn't that work?
Was it the test or the new code?
AH! It's the new code. Okay...
Green.

A: Why do you use a ticket tracker?
B: We have thousands of backlog entries.

A: wait... what? Why? How does that help?
B: If we don't store them, we may forget. A: if you have a list of thousands, you'll remember them all?
B: No, but if we review it we can see that we stored them and might pull them into the sprint.

A: How often do you do that?
B: We don't, there's always too much new work.

Sometimes you cannot plan. This is either because of the prevailing circumstances (chaos, complexity, extreme complication, dependency) or because you just don't know how.
In those cases, you set an intention and take advantage of opportunities. At the end of the road, looking back, an excellent opportunist or an exquisite planner will not only have the same results, but their paths are indistinguishable.

“How long does a 2-point story usually take?”
“We peg story points to half-days so 2 points is one day.”
“Yes, how long does a 2-point story usually take?”
“One day.”
“Historically, or ideally?”
“One day.”
“Most of the features you released are over 40 days old.”
“But, um….” “So 40 days is more than one day, right?”
“Yeah, but the coding part only takes one day.”
“Are you sure. Did you check the actuals on that?”
“No, but they are estimated for one day, so it’s got to be pretty close.”
“But is it?”
“Now that you mention it, no.”

If I had to work in an editor that didn't have refactoring support, I probably wouldn't refactor much either.

I'd rather leave a bad name in place than have to manually go to EVERY PLACE in the code where it's referenced and fix it by hand. It's oddly less bad to move a method from one class to another. I know techniques to get away with that easily.

The recipes in Refactoring (Fowler) work just fine, but they're more steps than just pressing a hotkey.

There is a problem in the way people hear “interacting” and “refactoring” — they think that it means stopping the work.

“Interaction” and “collaboration” are heard to mean “stop working and go to a meeting. “Refactor” sounds like you stop developing and make it look fancy. With pair-programming, customer on team, ensemble, swarming, etc the interaction is part of the making, not a break from it. Meetings are often the less productive & messier part of a day; working together tends to be highly productive and disciplined.

One of the more upsettingly radical things about the Manifesto for Agile Software Development is that it tells us that interactions are desirable.

It recommends intentionally interacting with other people in the work; something that is *still* being managed OUT of processes. This is one of the reasons that people said agile could NEVER WORK. It’s too messy, all this human stuff.

Add to that the idea that following a plan isn’t the highest good for a software team, that we should respond to change and late requirements… well, obviously doomed.

I read a story about a texas high school football team that "always lost." The team felt hopeless and defeated. A local millionaire decided to help, and told the players that if they won the playoffs, he would buy each of them a new car. As the story goes, the players too heart and were truly excited and motivated. They dreamed about their successes and their new car. They were different people; so excited and engaged.

A client of mine told me about an effort that was underway - heavy thinking, research & dev. One of the contributors came down with an illness, and the work stopped. They ended up being away with a protracted serious illness for 3 or 4 months in which time nothing happened. Having an individual assignment on a critical path is a thing that (I hope) we have learned to avoid in the age of COVID.
It's too common that we have to continue with some of our people out for an indefinite period.
And also The Great Resignation should have taught us.

“How do you know this world isn’t just a figment of your imagination?”

Primarily because what I expect and intend is not always what happens. If it were my imagination it would either work as I want/need, or it would fail for reasons inside me. The world, instead, surprises me in ways that I could not have seen coming. The reasons things turn out differently are not reasons I would have (or could have) imagined.

It teaches me things I did NOT know, instead of reinforcing my own biases and personality.

I worked with a team for a few weeks.
People built using TDD or very tight test-after.
It was all trunk-based with continuous deployment.
They formed up squads/swarms/groups as needed to get work done.
They turned around improvements in a day usually.
1/ They had never worked together before.
They'd never worked in ensembles before.
They'd never done CD or CI or TDD or TBD.
A few were somewhat experienced, some had never built software before.
2/

Naming is hard, so we should just use arbitrary names and try to keep them straight in our heads.

Custom types take effort so we should deeply nest native types and try to remember what each subscript means.

Code is hard, so transfer more burden to heads?

No thank you. This is an important point, not just Tim grousing.

"You should be smart enough to figure it out" takes the burden off the code to express itself, and onto the person to pay a lot of attention and maybe take notes.

It was a lot, this #agile2022. There are people I would have liked to visit that I saw only in passing. I spent a lot of time in the company of people, and made new friends as well as hanging with long-established friends. Overall, it was more people than I'm used to. I was rather exhausted as I'm not used to maintaining my energy. Being an introvert in a huge crowd takes some opportunism.

So "The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization."

So.... If you find a scrum team that isn't self-managing or self-organizing, I guess that the team is either still in the course of an ongoing transition or the SM is committing malpractice?

Nobody knows the whole system, nobody knows the whole stack, nobody knows the entire standard library for each of their *favorite* languages, nor the whole product community.

You need some advantages here... When all you have is one head, you need to augment your intelligence as much as you can. Keep browsers open, sure, and look things up quickly, but also checkers, linters, security scanners, syntax highlighting, formatters all IN THE IDE so they're active WHILE YOU CODE!

Divide And Conquer never (outside of certain software teams) meant “let’s split up and go it alone.’ That’s like a bad horror movie strategy.

You divide the enemy/problem into small parts that you can more easily defeat, not yourselves.

The force that is divided is conquered. This whole “let’s divide our forces so that we can be more easily defeated” idea is really quite daft. We don’t defeat the enemy by splitting up and going it alone.

If you have a big problem, divide the problem, not yourselves.
Your power is in combining your strengths.

You have a program you have to use every day. It has 48 fields on one screen, and an "okay" button at the bottom.
What you get depends on which fields you fill in... 1/ If you fill in fields 1-4, 12, 32, and 48 (you may have to scroll a bit) then it will create a new account, but don't touch fields other than those or it will attempt to either update or delete the account listed in field 32. 2/

I recall once when we built a huge distributed realtime system, and the client called in an analyst to perform a function point analysis.
The analyst said that there were only a dozen or so screens, & a handful of reports: the system should have taken a few weeks to build. Teammates said "dude! The screens and reports are the *least* part of what we've done. This isn't a store-and-report business system! It is a distributed control system!

The analyst wrote a one-sentence statement "this is a control system, so FP may not tell the whole story."

So, what do you think? Scrum, Inc:
scruminc.com/velocity/

You have a bug!
You don't understand it or you wouldn't have created it!
Okay. That's a good place to start. Okay, we look at it real hard and think about it. If we realize what's wrong (for sure) then we can fix it. We need to be really sure.

Hmmm... if we are really sure, we could write a test that duplicates the error, and then fixing it should make the test pass.