Tweet

Agile Otter Tim

1 Sep, 11 tweets, 2 min read

Just read a story about a new COO who started their first day on the job by cleaning the kitchen.
They drew a line saying that " spread the word that the next person I caught leaving a mess for their fellow employees to clean up would be shown the door."

Leaving a mess for their colleagues to clean up?
Sounds like Business As Usual in a lot of corporate software groups.
"If I don't do a good job, then that's okay. I can close the ticket and someone else will fix it."

Because, sadly, in many shops "getting things done" is "closing tickets."

"Look how much we did! We closed 20 tickets!"
"What can we demo today?"
"Well, nothing. It doesn't work yet and we can't deliver, but 20 tickets!"
"That's fine, then. Next sprint, we want 30 tickets."

This is a triumph of busyness over business.

In a lot of shops, only busyness counts for line-level employees, and only the busyness of the positional subordinates matters to managers, on up the etree.

Look how hard everyone works! How efficient and productive!

Quick Q: Why is laboring hard more important than delivering value?

What if your team could put new working system capabilities on the street in only a few hours a day, and they could spend an hour learning new skills, take a long lunch, and take off 1/2 hour early to go see movie together or walk in the park?

What if they could deliver 3x as fast, but their pace was leisurely? Would that be some kind of a failure?

What is the value of stress and busyness compared to actually delivering to the product community?

It's been busyness focused for at least 41 years.

Is there something important that I've continually missed and questioned? I used to do the 80-100 hour weeks, but I don't think we got more done that way. It was perhaps good theater, but it wasn't good practice.

Well, back from that digression, this idea of "scouting rules" (AKA boyscouting) the code base - why isn't that more popular?

It could form the basis for a lot of improvements in workplace behavior and efficiency.

Just don't leave a mess for someone else to fix/clean.

If you connect that and the idea of ratcheting (small steps forward without long falls backward) then you get continuous improvement.

And then connecting scouting rules with ratchets under a decision-making framework based on #ModernAgile and you've really got a cultural revolution.

Imagine it.

• • •

Missing some Tweet in this thread? You can try to force a refresh

This Thread may be Removed Anytime!

Twitter may remove this content at anytime! Save it as PDF for later use!

More from @tottinge

Agile Otter Tim

@tottinge

14 Sep

Primitive Obsession Detection:

when you see:
<primitive type> variablename;

See what methods the primitive type has which are not appropriate for the domain of variablename. What does type do that variable shouldn't?

string CustomerId;

What does string do that a customer ID shouldn't?
It can be
* passed as a time zone.
* upper/lower cased.
* concatenated to/with other strings
* passed as a filename to open()
* centered in a field of spaces
* used as a format in a print statement
* searched

int typeCode;

It can be:
* operated upon bitwise
* used as a port number
* treated as a boolean
* multiplied/divided/added/subtracted
* overflow/underflow
* passed to so many functions!!!

Read 7 tweets

Agile Otter Tim

@tottinge

3 Sep

Q: Why say "ensemble"? Just use the proper name "Mob Programming!" Is this just PC run amok?

A: I needed a term to encompass Pair Programming, Mob Programming, and Swarming. That it's inoffensive is a very nice and welcome bonus (worth it).

You know, people snigger when I say "pairing" as shorthand for pair-programming. It suggests sexual behaviors.

People also flinch when I say 'mobbing' because it is a term for grouping up to bully people in schools and workplaces.

"Grooming" is another - suggesting pedophilia.

We deal with words as they are used and try to not draw connotations we don't mean. That's just being clear.

"Ensemble" is a good category term. The other, better, term is "teamwork" but people have coopted that to mean all kinds of "working near but not together."

Read 8 tweets

Agile Otter Tim

@tottinge

10 Aug

Why don't you have tests?
Why don't you refactor?
Why is the code so bad?
Why can't we be responsive?
Why are we slowing down so much, so fast?

The problem with sprint packing (maximum amount of work per time box) is that people have to cut corners (including quality, design, testing) to make a tight deadline -- only to be given one equally tight or tighter.

Ad infinitum.

The kind of "go faster" that teams do to keep up with the work is like the driver ignoring warning lights, not getting tires changed, not washing the outside or throwing away trash.

It's an ugliness that piles up because there isn't time for caretaking.

Read 7 tweets

Agile Otter Tim

@tottinge

12 Jan

People often treat standardization as a self-evident good.
They want everyone to do everything the same way so it will be standard.
A short thread is in order here.

The primary reason we standardize things is for interoperability.

If we're not going to interoperate, then there's no point in standardizing.

If we ARE going to interoperate, then we need standard *interfaces* not standard everything.

This suggests that we don't need everyone on every team to work the same way, or for teams to operate (internally) the same way other teams interoperate.

Read 12 tweets

Agile Otter Tim

@tottinge

8 Dec 20

The most brilliant programmers alive working competitively in an ego-rich environment can’t get as much done as ordinary programmers working cooperatively as a self disciplined and self-organizing team. You need a process where team empowerment and collaboration thrive.

I'm very sorry that this quote didn't show up with quotations and a link. It should have. I'm not sure where it came from now.

This saddens me. I hope it's not lost.

agile-process.org
Don Wells

Read 4 tweets

Agile Otter Tim

@tottinge

3 Dec 20

You know what I don't do as a developer?
Memorize a big codebase.
I used to try, but then found I couldn't do it.
As a result, I have to make it scannable, discoverable, readable.

This has an unexpected benefit.

As it turns out, human memory is not a shared resource. There is an advantage to the person who knows how it all works, provided nothing changes (much).

But nobody else owns your memory, and it leaves with you.

I later found out that my "inability" to memorize a big code base is the reason people appreciated my code and found it useful and maintainable.

I didn't really do it for them at first, but as a survival tactic in a world where a lot of people had better memories than me.

Read 8 tweets

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!