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.
There is another concept, though: standard work.
Standard work in manufacturing is to ensure that everyone does the work the same way every time, consistently, as a basis for improving the work incrementally.
Fine if you're turning out N identical widgets per day, right?
Standard Work is constantly being updated and improved. THAT is the reason for standard work.
Whatever you do right now is your standard work.
Your input and your output vary constantly. They're never the same from job-to-job. What looks like "just add a button" to someone who isn't doing the work seems pretty standard, and you'll build it from standard components (ah, that interoperability thing), but it's unique.
If it already existed, you would not have to write it.
Once it exists, you will never write it again.
So if the input and output are constantly varied, what is "standard work" for you?
It seems that "standard work" can only apply to the habits (and micro-habits) you apply to doing your work every day, since it doesn't apply to the inputs and outputs.
How crucial is it that every person has an identical approach and set of habits? Should they be the same across teams doing different kind of work, in different stacks, for different clients? Or is that a place for only interface standardization (so teams can work together)?
Maybe there are habits we can share; approaches like TDD or DbC, version control behaviors (CI), or release behaviors (CD vs Big Bang).
But teams do different work, and may need different habits.
We shouldn't assume that standardizing all work identically is a good idea.
There is no way to standardize humans and it's not even a good idea to try. People bring themselves to the work (it's 11/12ths thinking, you know) and diversity results in better decisions and fewer defects.
Maybe next time you talk about standardizing anything, you'll think about which kinds of standardization you mean, which you really need, and where you should grow diversity instead of standardizing.
Maybe.
It's a choice.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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.
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.
One of the standard issues with going to swarming or mob programming is always "How will we spot the bad programmers then? How will we catch the people who are loafing? How will we spot underskilled people if they don't do individual work?"
I went as far as to add it to my slide deck when I am teaching whole-team structures. It is going to come up anyway, and people are usually glad it's already in the topics list.
Of course, the first thing I say is "I don't know. I've not seen it yet. Swarms seem to keep everyone involved and interested pretty much all the time." This is true. It's hard for people to believe.
We are once again offering the Technical Excellence Workshop as an open-enrollment experience this October.
It's an 8-week experience where we spend a few hours a week together, and we explore technical skills, perspectives, safety, behavioral skills, & leadership.
There is access to expert eLearning and there are exercises to perform during the week (some canned exercises, some live exploration) that will change how you look at your work and your organization.
Students from prior iterations have said that they had better interactions with their teams in the first week. Some claim that it made them better programmers. They have been able to initiate continuous improvement in their organizations.