So here's what I wanted to think on today: Continuous Improvement.

It has two features to consider:
* It's about making improvements
* It's continouous
Let's take the 'continuous' bit first:
* You're not in it for a burst or for a while, you're in for good.
* Nobody has completed their continuous improvement program. Ever.
* It's not "hopping from rock to rock" - improvements sustain and accumulate.
If you "improve" by expending greater physical effort and endurance, you can't do continuous improvement. Working harder isn't an improvement at all.

You have to sustain if you're to be continuous. Lower the level of effort necessary to succeed, don't brute force it.
Your budget for the next improvement will come from the time and energy saved by implementing the last improvement. How else could this possibly work?

Working harder is the reverse - it borrows energy from tomorrow in order to power through today.
Sometimes our experimental improvements don't pay off. That's part of the game. We may fail 1/5 or 4/5 times to find an improvement.

So the long view is important, but if we're not experimenting now, we will never find the improvements.

Continuous = Now AND later.
The other part is "improvement" and this is pretty key.
What defines an improvement? For whom?
Maybe one of my bosses is happier when they see I'm working overtime - is that an improvement? No. It doesn't sustain or scale or improve the bottom line.
The Pareto improvement makes one person's situation better without making other people's situation worse.

That's the right idea.

How can we have better outcomes as individuals, teams, organizations, and as a product community?

How can we have them more easily & often?
In a perfect world, we can make tomorrow better than yesterday - more safe, more fun, more competent, more human, more knowledgeable, easier, simpler, clearer.

Maybe that's too short a time frame (too advanced).

How about the same, but weeks?
Months?
What did we do this year that will make for more and easier accomplishments next year than last year?

What are we doing now to make next week better than last week?
It's continuous (eternal, now and later, always) so the improvements don't have to be big changes. Big changes are expensive and take a long time. What things can we "just do" without approval or funding?
Where is your accumulation of marginal gains, your two-second lean?

Where do you want to start today?
Consider these: industriallogic.com/blog/small-thi…
paulakers.net/books/2-second…

Find some inspiration to start. The savings from each improvement fuels & funds the next so maybe start small and soon.

• • •

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

Keep Current with Agile Otter Tim

Agile Otter Tim Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

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

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @tottinge

17 Nov
Lamenting with a friend that the majority of code we see in the wild is written by people who don't know the first thing about writing code.

Maybe we can muse on this? There is something interesting going on here.
I've seen two serious exceptions to the lament:

1. They are working with a technical coach.
2. They are in an ensemble

Otherwise, the best we can say most of the time is that it achieves the effect (often in the worst possible way).
Otherwise, any basic understanding of software design, coupling, cohesion, software organization, OO or functional, etc is not evidenced.
Read 5 tweets
17 Sep
So a given web application has an architecture which involves a UI and an API and under that some domain objects, data, etc.
When a new feature comes up, there is a gherkin test that does NOT go through selenium, but directly to the API. In developing the gherkin test, the team drives out the changes needed by the API and gets it working.
The gherkin test is a "story test" and checks to see if the system (behind the UI) works correctly. It does data, persistence, etc in a safe way.
Read 13 tweets
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
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
1 Sep
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."
Read 11 tweets
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

Did Thread Reader help you today?

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

Thank you for your support!

Follow Us on Twitter!

:(