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?
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.
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!!!
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."
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."
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.