Thread by @RonJeffries

The thing about a framework, Scrum, TDD, whatever, is that it is a massive simplification of how the thing "should" be done.

A good framework has rumble strips and guard rails. When you hit those, they alert you to issues that the beginner would likely miss on their own.

1/9

As such, the framework IS NOT TRUE. If you follow it blindly, you will probably be OK, but you'll not be doing as well as you could, nor as well as the framework provider has in mind.

2/9

You're supposed to look up when the rumble strip rumbles, and think about how you got off the road. You're supposed to survive hitting the guard rail, to think about maybe slowing down for curves.

3/9

Some experienced folks reject common frameworks because they're "wrong". Either they provide advice that is too vague to have meaning to a non-expert, or they elaborate the framework to make it more "true".

4/9

In my experience, I've always taken provided frameworks to heart ... and always assumed that when they didn't seem right, my job was to figure out, first, why there were right after all, and second, what to do when they just weren't right.

5/9

For a long time, when the framework turned out to be obviously wrong for this or that case, I wanted to fix the framework or toss it out.

In many cases, neither was the right thing to do.

6/9

The right thing to do is often to listen to what the framework tells us, and listen to what the work tells us, and judiciously choose, based on both, what to do.

As we grow, the framework in our head becomes far more than the one on paper.

7/9

But to me that doesn't devalue the Simple But Wrong framework. I've grown beyond it, but I did so in large part because the Simple But Wrong framework directed my thoughts to larger less simple things.

8/9

Yes, the above is a massive subtweet. If you suspect it's about you, it probably is.

Love ya, gang ...

9/9